<html>
  <head>
    <meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>FAST 2017-2019 | Elvis Zhang</title>
<meta name="description" content="The easy way or the right way." />
<link rel="shortcut icon" href="https://blog.shunzi.tech/favicon.ico">
<link rel="stylesheet" href="https://blog.shunzi.tech/styles/main.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.10.0/katex.min.css">

<script data-ad-client="ca-pub-7661668224317940" async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<script src="https://blog.shunzi.tech/media/js/jquery.min.js"></script>
<script src="https://blog.shunzi.tech/media/js/masonry.pkgd.min.js"></script>
<script src="https://blog.shunzi.tech/media/js/aos.js"></script>
<script src="https://blog.shunzi.tech/media/js/pace.min.js"></script>
<script src="https://blog.shunzi.tech/media/js/view-image.min.js"></script>
<script src="https://blog.shunzi.tech/media/js/jquery.magnific-popup.min.js"></script>
<script src="https://blog.shunzi.tech/media/js/functions.js"></script>
    <meta name="referrer" content="never">
    <meta name="description" content="

Paper bewtween FAST 2017 and FAST 2019
To know about hot topic in storage.
Will update to recent FAST.



FAST 2019
Pe..." />
    <meta name="keywords" content="Paper" />
    <script src="https://blog.shunzi.tech/media/js/waterfall.min.js"></script>
    <script src="https://blog.shunzi.tech/media/js/prism.min.js"></script>
  </head>
  <body>
            <header id="header" class="grid-container">
        <!-- start: .menu-wrapper -->
        <div class="menu-mobile"> 
          <i class="fa fa-reorder"></i>
        </div>
        <div class="menu-wrapper">
          <div class="">
            <div class="logo">
              <a href="https://blog.shunzi.tech"><img src="\media\images\custom-headerLogo.jpg" alt=""></a>
            </div>
            <!-- start: .main-nav -->

            <nav class="main-nav grid-container grid-parent">
              <ul id="menu-header" class="menu gradient-effect">
                <li class=""><a href="https://blog.shunzi.tech" class="menu">首页</a></li>
                
                  <li class="" >
                    <a href="/archives" class="menu">
                      归档
                    </a>
                  </li>
                
                  <li class="" >
                    <a href="/tag/diary" class="menu">
                      随笔
                    </a>
                  </li>
                
                  <li class="" >
                    <a href="/movies" class="menu">
                      观影
                    </a>
                  </li>
                
                  <li class="" >
                    <a href="/post/about" class="menu">
                      关于
                    </a>
                  </li>
                
                <li class="search-menu-item hide-on-mobile hide-on-tablet"><a href="#search-lightbox" class="lightbox mfp-inline"><i class="fa fa-search-line"></i></a></li>
              </ul>
            </nav>
            <a href="#search-lightbox" class="lightbox epcl-search-button mfp-inline hide-on-tablet hide-on-desktop"><i class="fa fa-search-line"></i></a>
            <!-- end: .main-nav -->
            <div class="clear"></div>
            <div class="border hide-on-tablet hide-on-mobile"></div>
          </div>    
          <div class="clear"></div>
        </div>
        <!-- end: .menu-wrapper -->
        <div class="clear"></div>
      </header>
      <div class="hide-on-mobile hide-on-tablet hide-on-desktop">
        <div id="search-lightbox" class="grid-container grid-small grid-parent mfp-hide">
          <div class="search-wrapper section">
            <form id="gridea-search-form" data-update="1620954331293" action="/search/index.html" class="search-form" _lpchecked="1">
              <input type="text" name="q" id="s" value="" class="search-field" placeholder="搜点啥..." aria-label="搜点啥..." required="">
              <button type="submit" class="submit" aria-label="Submit">
                <i class="fa fa-search-line"></i>
              </button>
            </form>
          </div>
        </div>
      </div>

      <main id="single" class="main grid-container fullcover no-sidebar aos-init aos-animate" data-aos="fade">

        <div class="center content">
          <div class="featured-image cover" style="background-image: url('https://blog.shunzi.tech/post-images/fast-2017-2019.png');">
            <div class="meta top"> 
              <time class="meta-info" style="float:left;" datetime="2020-01-09"><i class="fa fa-calendar"></i><span class="lately">1 年前</span></time>
              
              <a href="https://blog.shunzi.tech/post/fast-2017-2019/#comments" class="comments meta-info" title="">
                <i class="fa fa-comment remixicon"></i><span class="comment-count valine-comment-count" data-xid="/fast-2017-2019/"> </span>
              </a>
              <span id="/fast-2017-2019/" class="leancloud_visitors views-counter meta-info" title=""><i class="fa fa-leancloud remixicon"></i><span class="leancloud-visitors-count"></span></span>
              
            </div>
            <div class="info">
              <div class="tags ">
                
                      <a href="https://blog.shunzi.tech/tag/5uQUdLlSC/" class="ctag ctag-0 ctag-5uQUdLlSC" aria-label="">Paper</a>
                    
              </div>
              <h1 class="title ularge white bold">FAST 2017-2019</h1>
            </div>
          </div>
        </div>  

        <div class="epcl-page-wrapper">
          <div class="left-content grid-70 np-mobile">
            <article class="main-article post">
              <section class="post-content">
                <div class="text">
                  <blockquote>
<ul>
<li>Paper bewtween FAST 2017 and FAST 2019</li>
<li>To know about hot topic in storage.</li>
<li>Will update to recent FAST.</li>
</ul>
</blockquote>
<!--more-->
<h2 id="fast-2019">FAST 2019</h2>
<h3 id="persistent-memory-systems">Persistent Memory Systems</h3>
<h4 id="1-reaping-the-performance-of-fast-nvm-storage-with-udepot">1. Reaping the performance of fast NVM storage with uDepot.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/kourtis">Source</a></li>
</ul>
<h5 id="abstract">Abstract</h5>
<ul>
<li>
<p>Many applications require low-latency key-value storage, a requirement that is typically satisfied using key-value stores backed by DRAM. Recently, however, storage devices built on novel NVM technologies offer unprecedented performance compared to conventional SSDs. A key-value store that could deliver the performance of these devices would offer many opportunities to accelerate applications and reduce costs. Nevertheless, existing key-value stores, built for slower SSDs or HDDs, cannot fully exploit such devices.</p>
</li>
<li>
<p>In this paper, we present uDepot, a key-value store built bottom-up to deliver the performance of fast NVM block-based devices. uDepot is carefully crafted to avoid inefficiencies, uses a two-level indexing structure that dynamically adjusts its DRAM footprint to match the inserted items, and employs a novel task-based IO run-time system to maximize performance, enabling applications to use fast NVM devices at their full potential. As an embedded store, uDepot's performance nearly matches the raw performance of fast NVM devices both in terms of throughput and latency, while being scalable across multiple devices and cores. As a server, uDepot significantly outperforms state-of-the-art stores that target SSDs under the YCSB benchmark. Finally, using a Memcache service on top of uDepot we demonstrate that data services built on NVM storage devices can offer equivalent performance to their DRAM-based counterparts at a much lower cost. Indeed, using uDepot we have built a cloud Memcache service that is currently available as an experimental offering in the public cloud.</p>
</li>
</ul>
<h4 id="2-optimizing-systems-for-byte-addressable-nvm-by-reducing-bit-flipping">2. Optimizing Systems for Byte-Addressable NVM by Reducing Bit Flipping.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/bittman">Source</a></li>
</ul>
<h5 id="abstract-2">Abstract</h5>
<ul>
<li>
<p>New byte-addressable non-volatile memory (BNVM) technologies such as phase change memory (PCM) enable the construction of systems with large persistent memories, improving reliability and potentially reducing power consumption. However, BNVM technologies only support a limited number of lifetime writes per cell and consume most of their power when flipping a bit's state during a write; thus, PCM controllers only rewrite a cell's contents when the cell's value has changed. Prior research has assumed that reducing the number of words written is a good proxy for reducing the number of bits modified, but a recent study has suggested that this assumption may not be valid. Our research confirms that approaches with the fewest writes often have more bit flips than those optimized to reduce bit flipping.</p>
</li>
<li>
<p>To test the effectiveness of bit flip reduction, we built a framework that uses the number of bits flipped over time as the measure of &quot;goodness&quot; and modified a cycle-accurate simulator to count bits flipped during program execution. We implemented several modifications to common data structures designed to reduce power consumption and increase memory lifetime by reducing the number of bits modified by operations on several data structures: linked lists, hash tables, and red-black trees. We were able to reduce the number of bits flipped by up to 3.56× over standard implementations of the same data structures with negligible overhead. We measured the number of bits flipped by memory allocation and stack frame saves and found that careful data placement in the stack can reduce bit flips significantly. These changes require no hardware modifications and neither significantly reduce performance nor increase code complexity, making them attractive for designing systems optimized for BNVM.</p>
</li>
</ul>
<h4 id="3-write-optimized-dynamic-hashing-for-persistent-memory">3. Write-Optimized Dynamic Hashing for Persistent Memory.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/nam">Source</a></li>
</ul>
<h5 id="abstract-3">Abstract</h5>
<ul>
<li>Low latency storage media such as byte-addressable persistent memory (PM) requires rethinking of various data structures in terms of optimization. One of the main challenges in implementing hash-based indexing structures on PM is how to achieve efficiency by making effective use of cachelines while guaranteeing failure-atomicity for dynamic hash expansion and shrinkage. In this paper, we present Cacheline-Conscious Extendible Hashing (CCEH) that reduces the overhead of dynamic memory block management while guaranteeing constant hash table lookup time. CCEH guarantees failure-atomicity without making use of explicit logging. Our experiments show that CCEH effectively adapts its size as the demand increases under the fine-grained failure-atomicity constraint and reduces the maximum query latency by over two-thirds compared to the state-of-the-art hashing techniques.</li>
</ul>
<h4 id="4-software-wear-management-for-persistent-memories">4. Software Wear Management for Persistent Memories.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/gogte">Source</a></li>
</ul>
<h5 id="abstract-4">Abstract</h5>
<ul>
<li>
<p>The commercial release of byte-addressable persistent memories (PMs) is imminent. Unfortunately, these devices suffer from limited write endurance—without any wear management, PM lifetime might be as low as 1.1 months. Existing wear-management techniques introduce an additional indirection layer to remap memory across physical frames and require hardware support to track fine-grain wear. These mechanisms incur storage overhead and increase access latency and energy consumption.</p>
</li>
<li>
<p>We present Kevlar, an OS-based wear-management technique for PM that requires no new hardware. Kevlar uses existing virtual memory mechanisms to remap pages, enabling it to perform both wear leveling—shuffling pages in PM to even wear; and wear reduction—transparently migrating heavily written pages to DRAM. Crucially, Kevlar avoids the need for hardware support to track wear at fine grain. Instead, it relies on a novel wear estimation technique that builds upon Intel's Precise Event Based Sampling to approximately track processor cache contents via a software-maintained Bloom filter and estimate write-back rates at fine grain. We implement Kevlar in Linux and demonstrate that it achieves lifetime improvement of 18.4x (avg.) over no wear management while incurring 1.2% performance overhead.</p>
</li>
</ul>
<h3 id="file-systems">File Systems</h3>
<h4 id="1-storage-gardening-using-a-virtualization-layer-for-efficient-defragmentation-in-the-wafl-file-system">1. Storage Gardening: Using a Virtualization Layer for Efficient Defragmentation in the WAFL File System.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/kesavan">Source</a></li>
</ul>
<h5 id="abstract-5">Abstract</h5>
<ul>
<li>As a file system ages, it can experience multiple forms of fragmentation. Fragmentation of the free space in the file system can lower write performance and subsequent read performance. Client operations as well as internal operations, such as deduplication, can fragment the layout of an individual file, which also impacts file read performance. File systems that allow sub-block granular addressing can gather intra-block fragmentation, which leads to wasted free space. This paper describes how the NetApp® WAFL® file system leverages a storage virtualization layer for defragmentation techniques that physically relocate blocks efficiently, including those in read-only snapshots. The paper analyzes the effectiveness of these techniques at reducing fragmentation and improving overall performance across various storage media.</li>
</ul>
<h4 id="2-pay-migration-tax-to-homeland-anchor-based-scalable-reference-counting-for-multicores">2. Pay Migration Tax to Homeland: Anchor-based Scalable Reference Counting for Multicores.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/jung">Source</a></li>
</ul>
<h5 id="abstract-6">Abstract</h5>
<ul>
<li>The operating system community has been combating scalability bottlenecks for the past 10 years with victories or all the then-new multicore hardware. File systems, however, are in the midst of turmoil yet. One of the culprits behind performance degradation is reference counting widely used for managing data and metadata, and scalability is badly impacted under load with little or no logical contention, where the capability is desperately needed. To address this, we propose PAYGO, a reference counting technique that combines per-core hash of local reference counters with an anchor counter to make concurrent counting scalable as well as space-efficient, without having any other delay for managing counters. PAYGO imposes the restriction that decrement must be performed on the original local counter where the act of increment has occurred so that reclaiming zero-valued local counters can be done immediately. To this end, we enforce migrated processes running on different cores to update the anchor counter associated with the original local counter. We implemented PAYGO in the Linux page cache, and so our implementation is transparent to the file system. Experimental evaluation with underlying file systems (i.e., ext4, F2FS, btrfs, and XFS) demonstrated that PAYGO scales file systems better than other state-of-the-art techniques.</li>
</ul>
<h4 id="3-speculative-encryption-on-gpu-applied-to-cryptographic-file-systems">3. Speculative Encryption on GPU Applied to Cryptographic File Systems.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/eduardo">Source</a></li>
</ul>
<h5 id="abstract-7">Abstract</h5>
<ul>
<li>Due to the processing of cryptographic functions, Cryptographic File Systems (CFSs) may require significant processing capacity. Parallel processing techniques on CPUs or GPUs can be used to meet this demand. The CTR mode has two particularly useful features: the ability to be fully parallelizable and to perform the initial step of the encryption process ahead of time, generating encryption masks. This work presents an innovative approach in which the CTR mode is applied in the context of CFSs seeking to exploit these characteristics, including the anticipated production of the cipher masks (speculative encryption) in GPUs. Techniques that demonstrate how to deal with the issue of the generation, storage and management of nonces are presented, an essential component to the operation of the CTR mode in the context of CFSs. Related to GPU processing, our methods work to perform the handling of the encryption contexts and control the production of the masks, aiming to produce them with the adequate anticipation and overcome the extra latency due to encryption tasks. The techniques were applied in the implementation of EncFS++, a user space CFS. Performance analyzes showed that it was possible to achieve significant gains in throughput and CPU efficiency in several scenarios. They also demonstrated that GPU processing can be efficiently applied to CFS encryption workload even when working by encrypting small amounts of data (4 KiB), and in scenarios where higher speed/lower latency storage devices are used, such as SSDs or memory.</li>
</ul>
<h3 id="deduplication">Deduplication</h3>
<h4 id="1-sketching-volume-capacities-in-deduplicated-storage">1. Sketching Volume Capacities in Deduplicated Storage.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/harnik">Source</a></li>
</ul>
<h5 id="abstract-8">Abstract</h5>
<ul>
<li>The adoption of deduplication in storage systems has introduced significant new challenges for storage management. Specifically, the physical capacities associated with volumes are no longer readily available. In this work we introduce a new approach to analyzing capacities in deduplicated storage environments. We provide sketch-based estimations of fundamental capacity measures required for managing a storage system: How much physical space would be reclaimed if a volume or group of volumes were to be removed from a system (the {\em reclaimable} capacity) and how much of the physical space should be attributed to each of the volumes in the system (the {\em attributed} capacity). Our methods also support capacity queries for volume groups across multiple storage systems, e.g., how much capacity would a volume group consume after being migrated to another storage system? We provide analytical accuracy guarantees for our estimations as well as empirical evaluations. Our technology is integrated into a prominent all-flash storage array and exhibits high performance even for very large systems. We also demonstrate how this method opens the door for performing placement decisions at the data center level and obtaining insights on deduplication in the field.</li>
</ul>
<h4 id="2-finesse-fine-grained-feature-locality-based-fast-resemblance-detection-for-post-deduplication-delta-compression">2. Finesse: Fine-Grained Feature Locality based Fast Resemblance Detection for Post-Deduplication Delta Compression.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/zhang">Source</a></li>
</ul>
<h5 id="abstract-9">Abstract</h5>
<ul>
<li>In storage systems, delta compression is often used as a complementary data reduction technique for data deduplication because it is able to eliminate redundancy among the non-duplicate but highly similar chunks. Currently, what we call</li>
</ul>
<h4 id="3-sliding-look-back-window-assisted-data-chunk-rewriting-for-improving-deduplication-restore-performance">3. Sliding Look-Back Window Assisted Data Chunk Rewriting for Improving Deduplication Restore Performance.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/cao">Source</a></li>
</ul>
<h5 id="abstract-10">Abstract</h5>
<ul>
<li>
<p>Data deduplication is an effective way of improving storage space utilization. The data generated by deduplication is persistently stored in data chunks or data containers (a container consisting of a few hundreds or thousands of data chunks). The data restore process is rather slow due to data fragmentation and read amplification. To speed up the restore process, data chunk rewrite (a rewrite is to store a duplicate data chunk) schemes have been proposed to effectively improve data chunk locality and reduce the number of container reads for restoring the original data. However, rewrites will decrease the deduplication ratio since more storage space is used to store the duplicate data chunks.</p>
</li>
<li>
<p>To remedy this, we focus on reducing the data fragmentation and read amplification of container-based deduplication systems. We first propose a flexible container referenced count based rewrite scheme, which can make a better tradeoff between the deduplication ratio and the number of required container reads than that of capping which is an existing rewrite scheme. To further improve the rewrite candidate selection accuracy, we propose a sliding look-back window based design, which can make more accurate rewrite decisions by considering the caching effect, data chunk localities, and data chunk closeness in the current and future windows. According to our evaluation, our proposed approach can always achieve a higher restore performance than that of capping especially when the reduction of deduplication ratio is small.</p>
</li>
</ul>
<h3 id="storage-potpourri">Storage Potpourri</h3>
<h4 id="1-distcache-provable-load-balancing-for-large-scale-storage-systems-with-distributed-caching">1. DistCache: Provable Load Balancing for Large-Scale Storage Systems with Distributed Caching.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/liu">Source</a></li>
</ul>
<h5 id="abstract-11">Abstract</h5>
<ul>
<li>
<p>Load balancing is critical for distributed storage to meet strict service-level objectives (SLOs). It has been shown that a fast cache can guarantee load balancing for a clustered storage system. However, when the system scales out to multiple clusters, the fast cache itself would become the bottleneck. Traditional mechanisms like cache partition and cache replication either result in load imbalance between cache nodes or have high overhead for cache coherence.</p>
</li>
<li>
<p>We present DistCache, a new distributed caching mechanism that provides provable load balancing for large-scale storage systems. DistCache co-designs cache allocation with cache topology and query routing. The key idea is to partition the hot objects with independent hash functions between cache nodes in different layers, and to adaptively route queries with the power-of-two-choices. We prove that DistCache enables the cache throughput to increase linearly with the number of cache nodes, by unifying techniques from expander graphs, network flows, and queuing theory. DistCache is a general solution that can be applied to many storage systems. We demonstrate the benefits of DistCache by providing the design, implementation, and evaluation of the use case for emerging switch-based caching.</p>
</li>
</ul>
<h4 id="2-geardb-a-gc-free-key-value-store-on-hm-smr-drives-with-gear-compaction">2. GearDB: A GC-free Key-Value Store on HM-SMR Drives with Gear Compaction.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/yao">Source</a></li>
</ul>
<h5 id="abstract-12">Abstract</h5>
<ul>
<li>Host-managed shingled magnetic recording drives (HM-SMR) give a capacity advantage to harness the explosive growth of data. Applications where data is sequentially written and randomly read make the HM-SMR an ideal solution due to its capacity, predictable performance, and economical cost. Key-value stores based on the Log-Structured Merge Trees (LSM-trees) data structure is such a good fit due to their batched sequential writes. However, building an LSM-tree based KV store on HM-SMR drives presents severe challenges in maintaining the performance and space efficiency due to the redundant cleaning processes for applications and storage devices (i.e., compaction and garbage collections). To eliminate the overhead of on-disk garbage collections (GC) and improve compaction efficiency, this paper presents GearDB, a GC-free KV store tailored for HM-SMR drives, with three new techniques: a new on-disk data layout, compaction windows, and a novel gear compaction algorithm. We implement GearDB and evaluate it with LevelDB on a real HM-SMR drive. Our extensive experiments have shown that GearDB achieves good performance and space efficiency, i.e., on average <span class="katex"><span class="katex-mathml"><math><semantics><mrow><mn>1.71</mn><mo>×</mo></mrow><annotation encoding="application/x-tex">1.71\times</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.72777em;vertical-align:-0.08333em;"></span><span class="mord">1</span><span class="mord">.</span><span class="mord">7</span><span class="mord">1</span><span class="mord">×</span></span></span></span> faster than LevelDB in random write with a space efficiency of 89.9%.</li>
</ul>
<h4 id="3-speicher-securing-lsm-based-key-value-stores-using-shielded-execution">3. SPEICHER: Securing LSM-based Key-Value Stores using Shielded Execution.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/bailleu">Source</a></li>
</ul>
<h5 id="abstract-13">Abstract</h5>
<ul>
<li>
<p>We introduce Speicher, a secure storage system that not only provides strong confidentiality and integrity properties, but also ensures data freshness to protect against rollback/forking attacks. Speicher exports a Key-Value (KV) interface backed by Log-Structured Merge Tree (LSM) for supporting secure data storage and query operations. Speicher enforces these security properties on an untrusted host by leveraging shielded execution based on a hardware-assisted trusted execution environment (TEE)—specifically, Intel SGX. However, the design of Speicher extends the trust in shielded execution beyond the secure SGX enclave memory region to ensure that the security properties are also preserved in the stateful (or non-volatile) setting of an untrusted storage medium, including system crash, reboot, or migration.</p>
</li>
<li>
<p>More specifically, we have designed an authenticated and confidentiality-preserving LSM data structure. We have further hardened the LSM data structure to ensure data freshness by designing asynchronous trusted counters. Lastly, we designed a direct I/O library for shielded execution based on Intel SPDK to overcome the I/O bottlenecks in the SGX enclave. We have implemented Speicher as a fully-functional storage system by extending RocksDB, and evaluated its performance using the RocksDB benchmark. Our experimental evaluation shows that Speicher incurs reasonable overheads for providing strong security guarantees, while keeping the trusted computing base (TCB) small.</p>
</li>
</ul>
<h3 id="nvm-file-and-storage-systems">NVM File and Storage Systems</h3>
<h4 id="1-slm-db-single-level-key-value-store-with-persistent-memory">1. SLM-DB: Single-Level Key-Value Store with Persistent Memory.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/kaiyrakhmet">Source</a></li>
</ul>
<h5 id="abstract-14">Abstract</h5>
<ul>
<li>This paper investigates how to leverage emerging byte-addressable persistent memory (PM) to enhance the performance of key-value (KV) stores. We present a novel KV store, the Single-Level Merge DB (SLM-DB), which takes advantage of both the B+-tree index and the Log-Structured Merge Trees (LSM-tree) approach by making the best use of fast persistent memory. Our proposed SLM-DB achieves high read performance as well as high write performance with low write amplification and near-optimal read amplification. In SLM-DB, we exploit persistent memory to maintain a B+-tree index and adopt an LSM-tree approach to stage inserted KV pairs in a PM resident memory buffer. SLM-DB has a single-level organization of KV pairs on disks and performs selective compaction for the KV pairs, collecting garbage and keeping the KV pairs sorted sufficiently for range query operations. Our extensive experimental study demonstrates that, in our default setup, compared to LevelDB, SLM-DB provides 1.07 - 1.96 and 1.56 - 2.22 times higher read and write throughput, respectively, as well as comparable range query performance.</li>
</ul>
<h4 id="2-ziggurat-a-tiered-file-system-for-non-volatile-main-memories-and-disks">2. Ziggurat: A Tiered File System for Non-Volatile Main Memories and Disks.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/zheng">Source</a></li>
</ul>
<h5 id="abstract-15">Abstract</h5>
<ul>
<li>Emerging fast, byte-addressable Non-Volatile Main Memory (NVMM) provides huge increases in storage performance compared to traditional disks. We present Ziggurat, a tiered file system that combines NVMM and slow disks to create a storage system with near-NVMM performance and large capacity. Ziggurat steers incoming writes to NVMM, DRAM, or disk depending on application access patterns, write size, and the likelihood that the application will stall until the write completes. Ziggurat profiles the application's access stream online to predict the behavior of individual writes. In the background, Ziggurat estimates the &quot;temperature&quot; of file data, and migrates the cold file data from NVMM to disks. To fully utilize disk bandwidth, Ziggurat coalesces data blocks into large, sequential writes. Experimental results show that with a small amount of NVMM and a large SSD, Ziggurat achieves up to 38.9x and 46.5x throughput improvement compared with EXT4 and XFS running on an SSD alone, respectively. As the amount of NVMM grows, Ziggurat's performance improves until it matches the performance of an NVMM-only file system.</li>
</ul>
<h4 id="3-orion-a-distributed-file-system-for-non-volatile-main-memory-and-rdma-capable-networks">3. Orion: A Distributed File System for Non-Volatile Main Memory and RDMA-Capable Networks.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/yang">Source</a></li>
</ul>
<h5 id="abstract-16">Abstract</h5>
<ul>
<li>
<p>High-performance, byte-addressable non-volatile main memories (NVMMs) force system designers to rethink trade-offs throughout the system stack, often leading to dramatic changes in system architecture. Conventional distributed file systems are a prime example. When faster NVMM replaces block-based storage, the dramatic improvement in storage performance makes networking and software overhead a critical bottleneck.</p>
</li>
<li>
<p>In this paper, we present Orion, a distributed file system for NVMM-based storage. By taking a clean slate design and leveraging the characteristics of NVMM and high-speed, RDMA-based networking, Orion provides high-performance metadata and data access while maintaining the byte addressability of NVMM. Our evaluation shows Orion achieves performance comparable to local NVMM file systems and outperforms existing distributed file systems by a large margin.</p>
</li>
</ul>
<h3 id="big-systems">Big Systems</h3>
<h4 id="1-instalytics-cluster-filesystem-co-design-for-big-data-analytics">1. INSTalytics: Cluster Filesystem Co-design for Big-data Analytics.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/sivathanu">Source</a></li>
</ul>
<h5 id="abstract-17">Abstract</h5>
<ul>
<li>
<p>We present the design, implementation, and evaluation of Instalytics, a co-designed stack of a cluster file system and the compute layer, for efficient big data analytics in large-scale data centers. Instalytics amplifies the well-known benefits of data partitioning in analytics systems; instead of traditional partitioning on one dimension, Instalytics enables data to be simultaneously partitioned on four different dimensions at the same storage cost, enabling a larger fraction of queries to benefit from partition filtering and joins without network shuffle.</p>
</li>
<li>
<p>To achieve this, Instalytics uses compute-awareness to customize the 3-way replication that the cluster file system employs for availability. A new heterogeneous replication layout enables Instalytics to preserve the same recovery cost and availability as traditional replication. Instalytics also uses compute-awareness to expose a new {\em sliced-read} API that improves performance of joins by enabling multiple compute nodes to read slices of a data block efficiently via co-ordinated request scheduling and selective caching at the storage nodes.</p>
</li>
<li>
<p>We have implemented Instalytics in a production analytics stack, and show that recovery performance and availability is similar to physical replication, while providing significant improvements in query performance, suggesting a new approach to designing cloud-scale big-data analytics systems.</p>
</li>
</ul>
<h4 id="2-graphone-a-data-store-for-real-time-analytics-on-evolving-graphs">2. GraphOne: A Data Store for Real-time Analytics on Evolving Graphs.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/kumar">Source</a></li>
</ul>
<h5 id="abstract-18">Abstract</h5>
<ul>
<li>There is a growing need to perform real-time analytics on evolving graphs in order to deliver the values of big data to users. The key requirement from such applications is to have a data store to support their diverse data access efficiently, while concurrently ingesting fine-grained updates at a high velocity. Unfortunately, current graph systems, either graph databases or analytics engines, are not designed to achieve high performance for both operations. To address this challenge, we have designed and developed GraphOne, a graph data store that combines two complementary graph storage formats (edge list and adjacency list), and uses dual versioning to decouple graph computations from updates. Importantly, it presents a new data abstraction, GraphView, to enable data access at two different granularities with only a small data duplication. Experimental results show that GraphOne achieves an ingestion rate of two to three orders of magnitude higher than graph databases, while delivering algorithmic performance comparable to a static graph system. GraphOne is able to deliver 5.36x higher update rate and over 3x better analytics performance compared to a state-of-the-art dynamic graph system.</li>
</ul>
<h4 id="3-automatic-application-aware-io-forwarding-resource-allocation">3. Automatic, Application-Aware I/O Forwarding Resource Allocation.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/ji">Source</a></li>
</ul>
<h5 id="abstract-19">Abstract</h5>
<ul>
<li>
<p>The I/O forwarding architecture is widely adopted on modern supercomputers, with a layer of intermediate nodes sitting between the many compute nodes and backend storage nodes. This allows compute nodes to run more efficiently and stably with a leaner OS, offloads I/O coordination and communication with backend from the compute nodes, maintains less concurrent connections to storage systems, and provides additional resources for effective caching, prefetching, write buffering, and I/O aggregation. However, with many existing machines, these forwarding nodes are assigned to serve fixed set of compute nodes.</p>
</li>
<li>
<p>We explore an automatic mechanism, DFRA, for application-adaptive dynamic forwarding resource allocation. With I/O monitoring data that proves affordable to acquire in real time and maintain for long-term history analysis, Upon each job's dispatch, DFRA conducts a history-based study to determine whether the job should be granted more forwarding resources or given dedicated forwarding nodes. Such customized I/O forwarding lets the small fraction of I/O-intensive applications achieve higher I/O performance and scalability, meanwhile effectively isolating disruptive I/O activities. We implemented, evaluated, and deployed DFRA on Sunway TaihuLight, the current No.2 supercomputer in the world. It improves applications' I/O performance by up to 16.0x, eliminates most of the inter-application I/O interference, and has saved over 200 million of core-hours during its deployment on TaihuLight for past 8 months. Finally, our proposed DFRA design is not platform-dependent, making it applicable to the management of existing and future I/O forwarding or burst buffer resources.</p>
</li>
</ul>
<h3 id="flash-and-emerging-storage-systems">Flash and Emerging Storage Systems</h3>
<h4 id="1-design-tradeoffs-for-ssd-reliability">1. Design Tradeoffs for SSD Reliability.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/kim-bryan">Source</a></li>
</ul>
<h5 id="abstract-20">Abstract</h5>
<ul>
<li>Flash memory-based SSDs are popular across a wide range of data storage markets, while the underlying storage medium—flash memory—is becoming increasingly unreliable. As a result, modern SSDs employ a number of in-device reliability enhancement techniques, but none of them offers a one size fits all solution when considering the multi-dimensional requirements for SSDs: performance, reliability, and lifetime. In this paper, we examine the design tradeoffs of existing reliability enhancement techniques such as data re-read, intra-SSD redundancy, and data scrubbing. We observe that an uncoordinated use of these techniques adversely affects the performance of the SSD, and careful management of the techniques is necessary for a graceful performance degradation while maintaining a high reliability standard. To that end, we propose a holistic reliability management scheme that selectively employs redundancy, conditionally re-reads, judiciously selects data to scrub. We demonstrate the effectiveness of our scheme by evaluating it across a set of I/O workloads and SSDs wear states.</li>
</ul>
<h4 id="2-fully-automatic-stream-management-for-multi-streamed-ssds-using-program-contexts">2. Fully Automatic Stream Management for Multi-Streamed SSDs Using Program Contexts.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/kim-taejin">Source</a></li>
</ul>
<h5 id="abstract-21">Abstract</h5>
<ul>
<li>Multi-streamed SSDs can significantly improve both the performance and lifetime of flash-based SSDs when their streams are properly managed. However, existing stream management solutions do not adequately support the multi-streamed SSDs for their wide adoption. No existing stream management technique works in a fully automatic fashion for general I/O workloads. Furthermore, the limited number of available streams makes it difficult to effectively manage streams when a large number of streams are required. In this paper, we propose a fully automatic stream management technique, PCStream, which can work efficiently for general I/O workloads with heterogeneous write characteristics. PCStream is based on the key insight that stream allocation decisions should be made on dominant I/O activities. By identifying dominant I/O activities using program contexts, PCStream fully automates the whole process of stream allocation within the kernel with no manual work. In order to overcome the limited number of supported streams, we propose a new type of streams, internal streams, which can be implemented at low cost. PCStream can effectively double the number of available streams using internal streams. Our evaluations on real multi-streamed SSDs show that PCStream achieves the same efficiency as highly-optimized manual allocations by experienced programmers. PCStream improves IOPS by up to 56% over the existing automatic technique by reducing the garbage collection overhead by up to 69%.</li>
</ul>
<h4 id="3-large-scale-graph-processing-on-emerging-storage-devices">3. Large-Scale Graph Processing on Emerging Storage Devices.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/elyasi">Source</a></li>
</ul>
<h5 id="abstract-22">Abstract</h5>
<ul>
<li>Graph processing is becoming commonplace in many applications to analyze huge datasets. Much of the prior work in this area has assumed I/O devices with considerable latencies, especially for random accesses, using large amount of DRAM to trade-off additional computation for I/O accesses. However, emerging storage devices, including currently popular SSDs, provide fairly comparable sequential and random accesses, making these prior solutions inefficient. In this paper, we point out this inefficiency, and propose a new graph partitioning and processing framework to leverage these new device capabilities. We show experimentally on an actual platform that our proposal can give 2X better performance than a state-of-the-art solution.</li>
</ul>
<h3 id="erasure-coding-and-reliability">Erasure Coding and Reliability</h3>
<h4 id="1-fast-erasure-coding-for-data-storage-a-comprehensive-study-of-the-acceleration-techniques">1. Fast Erasure Coding for Data Storage: A Comprehensive Study of the Acceleration Techniques.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/zhou">Source</a></li>
</ul>
<h5 id="abstract-23">Abstract</h5>
<ul>
<li>Various techniques have been proposed in the literature to improve erasure code computation efficiency, including optimizing bitmatrix design, optimizing computation schedule, common XOR operation reduction, caching management techniques, and vectorization techniques. These techniques were largely proposed individually previously, and in this work, we seek to use them jointly. In order to accomplish this task, these techniques need to be thoroughly evaluated individually, and their relation better understood. Building on extensive test results, we develop methods to systematically optimize the computation chain together with the underlying bitmatrix. This led to a simple design approach of optimizing the bitmatrix by minimizing a weighted cost function, and also a straightforward erasure coding procedure: use the given bitmatrix to produce the computation schedule, which utilizes both the XOR reduction and caching management techniques, and apply XOR level vectorization. This procedure can provide a better performance than most existing techniques, and even compete against well-known codes such as EVENODD, RDP, and STAR codes. Moreover, the result suggests that vectorizing the XOR operation is a better choice than directly vectorizing finite field operations, not only because of the better encoding throughput, but also its minimal migration efforts onto newer CPUs.</li>
</ul>
<h4 id="2-openec-toward-unified-and-configurable-erasure-coding-management-in-distributed-storage-systems">2. OpenEC: Toward Unified and Configurable Erasure Coding Management in Distributed Storage Systems.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/li">Source</a></li>
</ul>
<h5 id="abstract-24">Abstract</h5>
<ul>
<li>Erasure coding becomes a practical redundancy technique for distributed storage systems to achieve fault tolerance with low storage overhead. Given its popularity, research studies have proposed theoretically proven erasure codes or efficient repair algorithms to make erasure coding more viable. However, integrating new erasure coding solutions into existing distributed storage systems is a challenging task and requires non-trivial re-engineering of the underlying storage workflows. We present OpenEC, a unified and configurable framework for readily deploying a variety of erasure coding solutions into existing distributed storage systems. OpenEC decouples erasure coding management from the storage workflows of distributed storage systems, and provides erasure coding designers with configurable controls of erasure coding operations through a directed-acyclic-graph-based programming abstraction. We prototype OpenEC on two versions of HDFS with limited code modifications. Experiments on a local cluster and Amazon EC2 show that OpenEC preserves both the operational performance and the properties of erasure coding solutions; OpenEC can also automatically optimize erasure coding operations to improve repair performance.</li>
</ul>
<h4 id="3-cluster-storage-systems-gotta-have-heart-improving-storage-efficiency-by-exploiting-disk-reliability-heterogeneity">3. Cluster storage systems gotta have HeART: improving storage efficiency by exploiting disk-reliability heterogeneity.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/kadekodi">Source</a></li>
</ul>
<h5 id="abstract-25">Abstract</h5>
<ul>
<li>Large-scale cluster storage systems typically consist of a heterogeneous mix of storage devices with significantly varying failure rates. Despite such differences among devices, redundancy settings are generally configured in a one-scheme-for-all fashion. In this paper, we make a case for exploiting reliability heterogeneity to tailor redundancy settings to different device groups. We present HeART, an online tuning tool that guides selection of, and transitions between redundancy settings for long-term data reliability, based on observed reliability properties of each disk group. By processing disk failure data over time, HeART identifies the boundaries and steady-state failure rate for each deployed disk group (e.g., by make/model). Using this information, HeART suggests the most space-efficient redundancy option allowed that will achieve the specified target data reliability. Analysis of longitudinal failure data for a large production storage cluster shows the robustness of HeART's failure-rate determination algorithms. The same analysis shows that a storage system guided by HeART could provide target data reliability levels with fewer disks than one-scheme-for-all approaches: 11–16% fewer compared to erasure codes like 10-of-14 or 6-of-9 and 33% fewer compared to 3-way replication.</li>
</ul>
<h4 id="4-scalecheck-a-single-machine-approach-for-discovering-scalability-bugs-in-large-distributed-systems">4. ScaleCheck: A Single-Machine Approach for Discovering Scalability Bugs in Large Distributed Systems.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast19/presentation/stuardo">Source</a></li>
</ul>
<h5 id="abstract-26">Abstract</h5>
<ul>
<li>We present ScaleCheck, an approach for discovering scalability bugs (a new class of bug in large storage systems) and for democratizing large-scale testing. ScaleCheck employs a program analysis technique, for finding potential causes of scalability bugs, and a series of colocation techniques, for testing implementation code at real scales but doing so on just a commodity PC. ScaleCheck has been integrated to several large-scale storage systems, Cassandra, HDFS, Riak, and Voldemort, and successfully exposed known and unknown scalability bugs, up to 512-node scale on a 16-core PC.</li>
</ul>
<h2 id="fast-2018">FAST 2018</h2>
<h3 id="failing-and-recovering">Failing and Recovering</h3>
<h4 id="1-fail-slow-at-scale-evidence-of-hardware-performance-faults-in-large-production-systems">1. Fail-Slow at Scale: Evidence of Hardware Performance Faults in Large Production Systems.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/gunawi">Source</a></li>
</ul>
<h5 id="abstract-27">Abstract</h5>
<ul>
<li>Fail-slow hardware is an under-studied failure mode. We present a study of 101 reports of fail-slow hardware incidents, collected from large-scale cluster deployments in 12 institutions. We show that all hardware types such as disk, SSD, CPU, memory and network components can exhibit performance faults. We made several important observations such as faults convert from one form to another, the cascading root causes and impacts can be long, and fail-slow faults can have varying symptoms. From this study, we make suggestions to vendors, operators, and systems designers.</li>
</ul>
<h4 id="2-protocol-aware-recovery-for-consensus-based-storage">2. Protocol-Aware Recovery for Consensus-Based Storage.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/alagappan">Source</a></li>
</ul>
<h5 id="abstract-28">Abstract</h5>
<ul>
<li>We introduce protocol-aware recovery (PAR), a new approach that exploits protocol-specific knowledge to correctly recover from storage faults in distributed systems. We demonstrate the efficacy of PAR through the design and implementation of corruption-tolerant replication (CTRL), a PAR mechanism specific to replicated state machine (RSM) systems. We experimentally show that the CTRL versions of two systems, LogCabin and ZooKeeper, safely recover from storage faults and provide high availability, while the unmodified versions can lose data or become unavailable. We also show that the CTRL versions have little performance overhead.</li>
</ul>
<h4 id="3-wafl-iron-repairing-live-enterprise-file-systems">3. WAFL Iron: Repairing Live Enterprise File Systems.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/kesavan">Source</a></li>
</ul>
<h5 id="abstract-29">Abstract</h5>
<ul>
<li>Consistent and timely access to an arbitrarily damaged file system is an important requirement of enterprise class systems. Repairing file system inconsistencies is accomplished most simply when file system access is limited to the repair tool. Checking and repairing a file system while it is open for general access present unique challenges. In this paper, we explore these challenges, present our online repair tool for the NetApp® WAFL® file system, and show how it achieves the same results as offline repair even while client access is enabled. We present some implementation details and evaluate its performance. To the best of our knowledge, this publication is the first to describe a fully functional online repair tool.</li>
</ul>
<h3 id="revealing-flashy-secrets">Revealing Flashy Secrets</h3>
<h4 id="1-mqsim-a-framework-for-enabling-realistic-studies-of-modern-multi-queue-ssd-devices">1. MQSim: A Framework for Enabling Realistic Studies of Modern Multi-Queue SSD Devices.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/tavakkol">Source</a></li>
</ul>
<h5 id="abstract-30">Abstract</h5>
<ul>
<li>
<p>Solid-state drives (SSDs) are used in a wide array of computer systems today, including in datacenters and enterprise servers.  As the I/O demands of these systems have increased, manufacturers have evolved SSD design to keep up with this demand.  For example, manufacturers have introduced new high-bandwidth interfaces to replace the traditional SATA protocol.  These new interfaces, such as the NVMe protocol, are designed specifically to enable the high amount  of concurrent I/O that SSDs are capable of delivering.</p>
</li>
<li>
<p>While modern SSDs with sophisticated features such as the NVMe protocol are  already on the market, SSD simulation tools have fallen behind, as they do not capture these new features.  We compare the outputs of these simulators  to the performance measured from real off-the-shelf SSDs, and find three major shortcomings in state-of-the-art SSD simulators.</p>
</li>
<li>
<p>First, existing simulators do not model critical features of new protocols like  NVMe, such as their use of multiple application-level queues for requests and the elimination of OS intervention. Second, existing simulators do not capture the effects of advanced SSD maintenance algorithms (e.g., garbage collection), as they do not properly emulate the steady-state conditions that exist in real SSDs. Third, existing simulators do not capture the full end-to-end latency of I/O requests, which can incorrectly skew the simulated behavior of SSDs that use emerging memory technologies, such as 3D XPoint. We show that without the accurate modeling of these features, results from existing simulators deviate significantly from real SSD performance.</p>
</li>
<li>
<p>In this work, we introduce a new simulator, called MQSim, that accurately models the performance of both modern SSDs and conventional SATA-based SSDs. MQSim faithfully models new high-bandwidth protocol implementations, steady-state SSD conditions, and the full end-to-end latency for requests in modern SSDs.   We validate MQSim using several modern SSDs, and show that MQSim uncovers several real and important issues that were not captured by existing simulators, such as the performance impact of inter-flow interference in modern SSDs. We plan to release MQSim as an open-source tool, and we hope that it can enable several new research directions in the future.</p>
</li>
</ul>
<h4 id="2-pen-design-and-evaluation-of-partial-erase-for-3d-nand-based-high-density-ssds">2. PEN: Design and Evaluation of Partial-Erase for 3D NAND-Based High Density SSDs.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/liu">Source</a></li>
</ul>
<h5 id="abstract-31">Abstract</h5>
<ul>
<li>3D NAND flash memories promise unprecedented flash storage capacities, which can be extremely important in certain application domains where both storage capacity and performance are first-class target metrics. However a block of 3D NAND flash contains many more pages than its 2D counterpart. This increased number of pages-per-block has numerous ramifications such as the longer erase latency, higher garbage collection costs, and increased write amplification factors, which can collectively prevent the 3D NAND flash products from becoming the mainstream in high-performance storage domain. In this paper, we introduce PEN, an architecture-level mechanism that enables partial-erase of flash blocks. Using our proposed partial-erase support, we also discuss how one can build a custom garbage collector for two types of flash translation layers (FTLs), namely, block-level FTL and hybrid FTL. Our experimental evaluations of PEN with a set of diverse real storage workloads indicate that the proposed approach can shorten the write latency by <span class="katex"><span class="katex-mathml"><math><semantics><mrow><mn>44.3</mn><mi mathvariant="normal">%</mi></mrow><annotation encoding="application/x-tex">44.3\%</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.80556em;vertical-align:-0.05556em;"></span><span class="mord">4</span><span class="mord">4</span><span class="mord">.</span><span class="mord">3</span><span class="mord">%</span></span></span></span> and <span class="katex"><span class="katex-mathml"><math><semantics><mrow><mn>47.9</mn><mi mathvariant="normal">%</mi></mrow><annotation encoding="application/x-tex">47.9\%</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.80556em;vertical-align:-0.05556em;"></span><span class="mord">4</span><span class="mord">7</span><span class="mord">.</span><span class="mord">9</span><span class="mord">%</span></span></span></span> for block-level FTL and hybrid FTL, respectively.</li>
</ul>
<h4 id="3-the-case-of-femu-cheap-accurate-scalable-and-extensible-flash-emulator">3. The CASE of FEMU: Cheap, Accurate, Scalable and Extensible Flash Emulator.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/li">Source</a></li>
</ul>
<h5 id="abstract-32">Abstract</h5>
<ul>
<li>
<p>We present FEMU, a QEMU-based flash emulator for fostering future full-stack software/hardware SSD research, with the following four &quot;CASE&quot; benefits. FEMU is cheap ($0) as it will be an open-sourced software; FEMU is relatively accurate, with only 0.5-38% variance from OpenChannel SSD in our tests; FEMU is scalable, upon our optimized QEMU stack, to support up to 32 parallel channels/chips without unintended queueing</p>
</li>
<li>
<p>delays; FEMU is extensible, enabling various types of SSD research, such as internal-SSD, kernel-only and split-level research on it.</p>
</li>
</ul>
<h3 id="understanding-the-metadata-story">Understanding the Meta(data) Story</h3>
<h4 id="1-spiffy-enabling-file-system-aware-storage-applications">1. Spiffy: Enabling File-System Aware Storage Applications.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/sun">Source</a></li>
</ul>
<h5 id="abstract-33">Abstract</h5>
<ul>
<li>
<p>Many file system applications such as defragmentation tools, file system checkers or data recovery tools, operate at the storage layer. Today, developers of these storage applications require detailed knowledge of the file system format, which takes a significant amount of time to learn, often by trial and error, due to insufficient documentation or specification of the format. Furthermore, these applications perform ad-hoc processing of the file-system metadata, leading to bugs and vulnerabilities.</p>
</li>
<li>
<p>We propose Spiffy, an annotation language for specifying the on-disk format of a file system. File system developers annotate the data structures of a file system, and we use these annotations to generate a library that allows identifying, parsing and traversing file-system metadata, providing support for both offline and online storage applications. This approach simplifies the development of storage applications that work across different file systems because it reduces the amount of file-system specific code that needs to be written.</p>
</li>
<li>
<p>We have written annotations for the Linux Ext4, Btrfs and F2FS file systems, and developed several applications for these file systems, including a type-specific metadata corruptor, a file system converter, and an online storage layer cache that preferentially caches files for certain users. Our experiments show that applications that use the library to access file system metadata can achieve good performance and are robust against file system corruption errors.</p>
</li>
</ul>
<h4 id="2-towards-robust-file-system-checkers">2. Towards Robust File System Checkers.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/gatla">Source</a></li>
</ul>
<h5 id="abstract-34">Abstract</h5>
<ul>
<li>
<p>File systems may become corrupted for many reasons despite various protection techniques. Therefore, most file systems come with a checker to recover the file system to a consistent state. However, existing checkers are commonly assumed to be able to complete the repair without interruption, which may not be true in practice.</p>
</li>
<li>
<p>In this work, we demonstrate via fault injection experiments that checkers of widely used file systems may leave the file system in an uncorrectable state if the repair procedure is interrupted unexpectedly. To address the problem, we first fix the ordering issue in the undo logging of e2fsck, and then build a general logging library (i.e., rfsck-lib) for strengthening checkers. To demonstrate the practicality, we integrate rfsck-lib with existing checkers and create two new checkers: (1) rfsck-ext, a robust checker for Ext-family file systems, and (2) rfsck-xfs, a robust checker for XFS file system, both of which require only tens of lines of modification to the original versions. Both rfsck-ext and rfsck-xfs are resilient to faults in our experiments. Also, both checkers incur reasonable performance overhead (i.e., up to 12%) comparing to the original unreliable versions. Moreover, rfsck-ext outperforms the patched e2fsck by up to nine times while achieving the same level of robustness.</p>
</li>
</ul>
<h4 id="3-the-full-path-to-full-path-indexing">3. The Full Path to Full-Path Indexing.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/zhan">Source</a></li>
</ul>
<h5 id="abstract-35">Abstract</h5>
<ul>
<li>
<p>This paper shows how to use full-path indexing in a file system to realize fast directory scans, writes, and renames. Prior results indicated that renames are prohibitively expensive in full-path indexing.</p>
</li>
<li>
<p>The paper introduces a range-rename mechanism for efficient key-space changes in a write-optimized dictionary. This mechanism is encapsulated in the key-value-store API, and simplifies the overall design of the file system.</p>
</li>
<li>
<p>We implemented this mechanism in ArborFS, an extension of the BetrFS in-kernel, local file system for Linux. For instance, ArborFS performs recursive greps 1.5x faster and random writes 1.2x faster than BetrFS, but renames are competitive with standard, indirection-based file systems for a range of sizes. ArborFS outperforms relative-path file systems such as BetrFS as well as traditional file systems such as ext4, xfs and zfs across a variety of workloads.</p>
</li>
</ul>
<h3 id="coding-hashing-hiding">Coding, Hashing, Hiding</h3>
<h4 id="1-clay-codes-moulding-mds-codes-to-yield-an-msr-code">1. Clay Codes: Moulding MDS Codes to Yield an MSR Code.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/vajha">Source</a></li>
</ul>
<h5 id="abstract-36">Abstract</h5>
<ul>
<li>
<p>With increase in scale, the number of node failures in a data center increases sharply.  To ensure availability of data, failure-tolerance schemes such as Reed-Solomon (RS) or more generally, Maximum Distance Separable (MDS) erasure codes are used. However, while MDS codes offer minimum storage overhead for a given amount of failure tolerance, they do not meet other practical needs of today's data centers. Although modern codes such as Minimum Storage Regenerating (MSR) codes are designed to meet these practical needs, they are available only in highly-constrained theoretical constructions, that are not sufficiently mature enough for practical implementation.  We present {\em Clay codes} that extract the best from both worlds. Clay (short for Coupled-Layer) codes are MSR codes that offer a simplified construction for decoding/repair by using pairwise coupling across multiple stacked layers of any single MDS code.</p>
</li>
<li>
<p>In addition, Clay codes provide the first practical implementation of an MSR code that offers (a) low storage overhead, (b) simultaneous optimality in terms of three key parameters: repair bandwidth, sub-packetization level and disk I/O, (c) uniform repair performance of data and parity nodes and (d) support for both single and multiple-node repairs, while permitting faster and more efficient repair.</p>
</li>
<li>
<p>While all MSR codes are vector codes, none of the distributed storage systems support vector codes. We have modified Ceph to support any vector code, and our contribution is now a part of Ceph's master codebase. We have implemented Clay codes, and integrated it as a plugin to Ceph. Six example Clay codes were evaluated on a cluster of Amazon EC2 instances and code parameters were carefully chosen to match known erasure-code deployments in practice. A particular example code, with storage overhead <span class="katex"><span class="katex-mathml"><math><semantics><mrow><mn>1.25</mn></mrow><annotation encoding="application/x-tex">1.25</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.64444em;vertical-align:0em;"></span><span class="mord">1</span><span class="mord">.</span><span class="mord">2</span><span class="mord">5</span></span></span></span>x, is shown to reduce repair network traffic by a factor of <span class="katex"><span class="katex-mathml"><math><semantics><mrow><mn>2.9</mn></mrow><annotation encoding="application/x-tex">2.9</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.64444em;vertical-align:0em;"></span><span class="mord">2</span><span class="mord">.</span><span class="mord">9</span></span></span></span> in comparison with RS codes and similar reductions are obtained for both repair time and disk read.</p>
</li>
</ul>
<h4 id="2-towards-web-based-delta-synchronization-for-cloud-storage-services">2. Towards Web-based Delta Synchronization for Cloud Storage Services.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/xiao">Source</a></li>
</ul>
<h5 id="abstract-37">Abstract</h5>
<ul>
<li>
<p>Delta synchronization (sync) is crucial for network-level efficiency of cloud storage services. Practical delta sync techniques are, however, only available for PC clients and mobile apps, but not web browsers---the most pervasive and OS-independent access method.  To understand the obstacles of web-based delta sync, we implement a delta sync solution, WebRsync, using state-of-the-art web techniques based on rsync, the de facto delta sync protocol for PC clients. Our measurements show that WebRsync severely suffers from the inefficiency of JavaScript execution inside web browsers, thus leading to frequent stagnation and even hanging.</p>
</li>
<li>
<p>Given that the computation burden on the web browser mainly stems from data chunk search and comparison, we reverse the traditional delta sync approach by lifting all chunk search and comparison operations from the client side to the server side. Inevitably, this brings considerable computation overhead to the servers. Hence, we further leverage locality-aware chunk matching and lightweight checksum algorithms to reduce the overhead. The resulting solution, WebR2sync+, outpaces WebRsync by an order of magnitude, and is able to simultaneously support 6800--8500 web clients' delta sync using a standard VM server instance based on a Dropbox-like system architecture.</p>
</li>
</ul>
<h4 id="3-stash-in-a-flash">3. Stash in a Flash.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/zuck">Source</a></li>
</ul>
<h5 id="abstract-38">Abstract</h5>
<ul>
<li>
<p>Encryption is a useful tool to protect data confidentiality. Yet it is still challenging to hide the very presence of encrypted, secret data from a powerful adversary. This paper presents a new technique to hide data in flash by manipulating the voltage level of pseudo-randomlyselected flash cells to encode two bits (rather than one) in the cell. In this model, we have one “public” bit interpreted using an SLC-style encoding, and extract a private bit using an MLC-style encoding. The locations of cells that encode hidden data is based on a secret key known only to the hiding user.</p>
</li>
<li>
<p>Intuitively, this technique requires that the voltage level in a cell encoding data must be (1) not statistically distinguishable from a cell only storing public data, and (2) the user must be able to reliably read the hidden data from this cell. Our key insight is that there is a wide enough variation in the range of voltage levels in a typical flash device to obscure the presence of fine-grained changes to a small fraction of the cells, and that the variation is wide enough to support reliably re-reading hidden data. We demonstrate that our hidden data and underlying voltage manipulations go undetected by support</p>
</li>
<li>
<p>vector machine based supervised learning which performs similarly to a random guess. The error rates of our scheme are low enough that the data is recoverable months after being stored. Compared to prior work, our technique provides 24x and 50x higher encoding and decoding throughput and doubles the capacity, while being 37x more power efficient.</p>
</li>
</ul>
<h3 id="new-media-and-old">New Media and Old</h3>
<h4 id="1-endurable-transient-inconsistency-in-byte-addressable-persistent-b-tree">1. Endurable Transient Inconsistency in Byte-Addressable Persistent B+-Tree.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/hwang">Source</a></li>
</ul>
<h5 id="abstract-39">Abstract</h5>
<ul>
<li>
<p>With the emergence of byte-addressable persistent memory (PM), a cache line, instead of a page, is expected to be the unit of data transfer between volatile and nonvolatile devices, but the failure-atomicity of write operations is guaranteed in the granularity of 8 bytes rather than cache lines. This granularity mismatch problem has generated interest in redesigning block-based data structures such as B+-trees, and attempts have been made to use in-memory data structures for PM. However, various methods of modifying B+-trees for PM degrade the efficiency of B+-trees due to the additional metadata and high rebalancing overhead caused by logging methods.</p>
</li>
<li>
<p>In this study, we develop Failure-Atomic ShifT (FAST) and Failure-Atomic In-place Rebalance (FAIR) algorithms.  FAST and FAIR modify legacy B+-trees in a byte-addressable fashion but solves the granularity mismatch problem.  Every 8-byte store instruction used in the FAST and FAIR algorithms transforms a B+-tree into another consistent state or a transient inconsistent state that read operations can tolerate.  By making read operations transient inconsistency, we can eliminate expensive copy-on-write, logging, and even the necessity of read latches so that read transactions can be non-blocking.   Our experimental results show that legacy B+-trees with FAST and FAIR schemes outperform the state-of-the-art persistent indexing structures by a large margin.</p>
</li>
</ul>
<h4 id="2-rflush-rethink-the-flush">2. RFLUSH: Rethink the Flush.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/yeon">Source</a></li>
</ul>
<h5 id="abstract-40">Abstract</h5>
<ul>
<li>A FLUSH command has been used for decades to enforce persistence and ordering of updates in a storage device. The command forces all the data in the volatile buffer to non-volatile media to achieve persistency. This lumpsum approach to flushing has two performance consequences. First, it slows down non-volatile materialization of the writes that actually need to be flushed. Second, it deprives the writes that need not to be flushed of an opportunity for absorbing future writes and coalescing. We attempt to characterize the problems of this semantic gap of flushing in storage devices and propose RFLUSH that allows a fine-grained control over flushing in them. The RFLUSH command delivers a range of LBAs that need to be flushed and thus enables the storage device to force only a subset of data in its buffer. We implemented this fine-grained flush command in a storage device using an open-source flash development platform and modified the F2FS file system to make use of the command in processing fsync requests as a case study. Performance evaluation using the prototype implementation shows that the inclusion of RFLUSH improves the throughput by up to 5.6x; reduces the write traffic by up to 43%; and eliminates the long tail in the response time.</li>
</ul>
<h4 id="3-barrier-enabled-io-stack-for-flash-storage">3. Barrier-Enabled IO Stack for Flash Storage.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/won">Source</a></li>
</ul>
<h5 id="abstract-41">Abstract</h5>
<ul>
<li>This work is dedicated to eliminating the overhead required for guaranteeing the storage order in the modern IO stack. The existing block device adopts a prohibitively expensive approach in ensuring the storage  order among write requests: interleaving the write requests  with Transfer-and-Flush. Exploiting the cache barrier command for Flash storage, we overhaul the IO scheduler, the dispatch module, and the filesystem so that these layers are orchestrated to preserve the ordering condition imposed by the application with which the associated data blocks are made durable. The key ingredients of Barrier-Enabled IO stack are Epoch-based IO scheduling, Order-Preserving Dispatch, and Dual-Mode Journaling. Barrier-enabled IO stack can control the storage order without Transfer-and-Flush overhead. We implement the barrier-enabled IO stack in server as well as in mobile platforms. SQLite performance increases by 270% and  75%, in server and in smartphone, respectively. In a server storage, BarrierFS brings as much as by 43<span class="katex"><span class="katex-mathml"><math><semantics><mrow><mo>×</mo></mrow><annotation encoding="application/x-tex">\times</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.66666em;vertical-align:-0.08333em;"></span><span class="mord">×</span></span></span></span> and by 73<span class="katex"><span class="katex-mathml"><math><semantics><mrow><mo>×</mo></mrow><annotation encoding="application/x-tex">\times</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.66666em;vertical-align:-0.08333em;"></span><span class="mord">×</span></span></span></span> performance gain in MySQL and SQLite, respectively, against EXT4 via relaxing the durability of a transaction.</li>
</ul>
<h3 id="long-live-the-file-system">Long Live the File System!</h3>
<h4 id="1-high-performance-transaction-processing-in-journaling-file-systems">1. High-Performance Transaction Processing in Journaling File Systems.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/son">Source</a></li>
</ul>
<h5 id="abstract-42">Abstract</h5>
<ul>
<li>Journaling file systems provide crash-consistency to applications by keeping track of uncommitted changes in the journal area (journaling) and writing committed changes to their original area at a certain point (checkpointing). They generally use coarse-grained locking to access shared data structures and perform I/O operations by a single thread. For these reasons, journaling file systems often face the problem of lock contention and underutilization of I/O bandwidth on multi-cores with high-performance storage.  To address these issues, we design journaling and checkpointing schemes that enable concurrent updates on data structures and parallelize I/O operations.  We implement our schemes in EXT4/JBD2 and evaluate them on a 72-core machine with a high-performance NVMe SSD. The experimental results show that our optimized file system improves the performance by up to about 2.2x and 1.5x compared to the existing EXT4 file system and a state-of-art scalable file system, respectively.</li>
</ul>
<h4 id="2-designing-a-true-direct-access-file-system-with-devfs">2. Designing a True Direct-Access File System with DevFS.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/kannan">Source</a></li>
</ul>
<h5 id="abstract-43">Abstract</h5>
<ul>
<li>We present DevFS, a direct-access file system embedded completely within a storage device. DevFS provides direct access without compromising file system integrity, concurrency, crash consistency, and security. A novel reverse-caching mechanism enables the usage of host memory for inactive objects, thus reducing memory load upon the device.  Evaluation of an emulated DevFS prototype shows more than 2x higher I/O throughput with direct access and up to a 78% reduction in device RAM utilization.</li>
</ul>
<h4 id="3-fstream-managing-flash-streams-in-the-file-system">3. FStream: Managing Flash Streams in the File System.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/rho">Source</a></li>
</ul>
<h5 id="abstract-44">Abstract</h5>
<ul>
<li>
<p>The performance and lifespan of a solid-state drive (SSD) depend not only on the current input workload but also on its internal media fragmentation formed over time. The recently proposed streams gives a means for the host system to control how data are placed on the physical media (abstrated by a stream) and effectively reduce the media fragmentation. This work proposes FStream, a file system approach to taking advantage of this facility. FStream extracts streams at the file system level and avoids complex application level data mapping to streams. Experimental results showed that FStream enhances the filebench performance by 5%-35% and reduces WAF (Write Amplification Factor) by 7%-46%. For a NoSQL database benchmark,</p>
</li>
<li>
<p>performance is improved by up to 38% and WAF</p>
</li>
<li>
<p>is reduced by up to 81%.</p>
</li>
</ul>
<h3 id="distribute-and-conquer">Distribute and Conquer</h3>
<h4 id="1-improving-docker-registry-design-based-on-production-workload-analysis">1. Improving Docker Registry Design Based on Production Workload Analysis.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/anwar">Source</a></li>
</ul>
<h5 id="abstract-45">Abstract</h5>
<ul>
<li>Containers offer an efficient way to run workloads as independent microservices that can be developed, tested and deployed in an agile manner. To facilitate this process, container frameworks offer a registry service that enables users to publish and version container images and share them with others. The registry service plays a critical role in the startup time of containers since many container starts entail the retrieval of container images from a registry. To support research efforts on optimizing the registry service, large-scale and realistic traces are required. In this paper, we perform a comprehensive characterization of a large-scale registry workload based on traces that we collected over the course of 75 days from five IBM data centers hosting production-level registries. We present a trace replayer to perform our analysis and infer a number of crucial insights about container workloads, such as request type distribution, access patterns, and response times. Based on these insights, we derive design implications for the registry and demonstrate their ability to improve performance. Both the traces and the replayer are open-sourced to facilitate further research.</li>
</ul>
<h4 id="2-raid-deterministic-and-balanced-data-distribution-for-large-disk-enclosures">2. RAID+: Deterministic and Balanced Data Distribution for Large Disk Enclosures.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/zhang">Source</a></li>
</ul>
<h5 id="abstract-46">Abstract</h5>
<ul>
<li>
<p>Existing RAID solutions partition large disk enclosures so that each RAID group uses its own disks exclusively. This achieves good performance isolation across underlying disk groups, at the cost of disk under-utilization and slow RAID reconstruction from disk failures.</p>
</li>
<li>
<p>We propose RAID+, a new RAID construction mechanism that spreads both normal I/O and reconstruction workloads to a larger disk pool in a balanced manner. Unlike systems conducting randomized placement, RAID+ employs deterministic addressing enabled by the mathematical properties of mutually orthogonal Latin squares, based on which it constructs 3-D data templates mapping a logical data volume to uniformly distributed disk blocks across all disks. While the total read/write volume remains unchanged, with or without disk failures, many more disk drives participate in data service and disk reconstruction. Our evaluation with a 60-drive disk enclosure using both synthetic and real-world workloads shows that RAID+ significantly speeds up data recovery while delivering better normal I/O performance and higher multi-tenant system throughput.</p>
</li>
</ul>
<h4 id="3-logical-synchronous-replication-in-the-tintri-vmstore-file-system">3. Logical Synchronous Replication in the Tintri VMstore File System.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/glass">Source</a></li>
</ul>
<h5 id="abstract-47">Abstract</h5>
<ul>
<li>A standard feature of enterprise data storage systems is synchronous replication: updates received from clients by one storage system are replicated to a remote storage system and are only acknowledged to clients after having been stored persistently on both storage systems. Traditionally these replication schemes require configuration on a coarse granularity, e.g. on a LUN, filesystem volume, or whole-system basis. In contrast to this, we present a new architecture which operates on a fine granularity---individual files and directories.  To implement this, we use a combination of novel per-file capabilities and existing techniques to solve the following problems: tracking parallel writes in flight on independent storage systems; replicating arbitrary filesystem operations; efficiently resynchronizing after a disconnect; and verifying the integrity of replicated data between two storage systems.</li>
</ul>
<h3 id="dedup">Dedup:</h3>
<p>Last but Not Least</p>
<h4 id="1-alacc-accelerating-restore-performance-of-data-deduplication-systems-using-adaptive-look-ahead-window-assisted-chunk-caching">1. ALACC: Accelerating Restore Performance of Data Deduplication Systems Using Adaptive Look-Ahead Window Assisted Chunk Caching.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/cao">Source</a></li>
</ul>
<h5 id="abstract-48">Abstract</h5>
<ul>
<li>
<p>Data deduplication has been widely applied in storage systems to improve the efficiency of space utilization. In data deduplication systems, the data restore performance is seriously hindered by read amplification since the accessed data chunks are scattered over many containers. A container consisting of hundreds or thousands data chunks is the data unit to be read from or write to the storage. Several schemes such as forward assembly, container-based caching, and chunk-based caching are used to reduce the number of container-reads during the restore process. However, how to effectively use these schemes to get the best restore performance is still unclear.</p>
</li>
<li>
<p>In this paper, we first study the trade-offs of using these schemes in terms of read amplification and computing time. We then propose a combined data chunk caching and forward assembly scheme called ALACC (Adaptive Look-Ahead Chunk Caching) for improving restore performance which can adapt to different deduplication workloads with a fixed total amount of memory. This is accomplished by extending and shrinking the look-ahead window adaptively to cover an appropriate data recipe range and dynamically deciding the memory to be allocated to forward assembly area and chunk-based caching. Our evaluations show the restore throughput of ALACC is higher than that of the optimum case of various configurations using the fixed amount of memory allocated to forward assembly and to chunk-based caching.</p>
</li>
</ul>
<h4 id="2-uksm-swift-memory-deduplication-via-hierarchical-and-adaptive-memory-region-distilling">2. UKSM: Swift Memory Deduplication via Hierarchical and Adaptive Memory Region Distilling.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast18/presentation/xia">Source</a></li>
</ul>
<h5 id="abstract-49">Abstract</h5>
<ul>
<li>In cloud computing, deduplication can reduce memory footprint by eliminating redundant pages. The responsiveness of a deduplication process to newly generated memory pages is critical. State-of-the-art Content Based Page Sharing (CBPS) approaches lack responsiveness as they equally scan every page while finding redundancies. We propose a new deduplication system UKSM, which prioritizes different memory regions to accelerate the deduplication process and minimize application penalty. With UKSM, memory regions are organized as a distilling hierarchy, where a region in a higher level receives more CPU cycles. UKSM adaptively promotes/demotes a region among levels according to the region’s estimated deduplication benefit and penalty. UKSM further introduces an adaptive partial-page hashing scheme which adjusts a global page hashing strength parameter according to the global degree of page similarity. Experiments demonstrate that, with the same amount of CPU cycles in the same time envelop, UKSM can achieve up to 12.6and 5 more memory saving than CBPS approaches on static and dynamic workloads, respectively.</li>
</ul>
<h2 id="fast-2017">FAST 2017</h2>
<h3 id="garbage">Garbage</h3>
<h4 id="1-algorithms-and-data-structures-for-efficient-free-space-reclamation-in-wafl">1. Algorithms and Data Structures for Efficient Free Space Reclamation in WAFL.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/kesavan">Source</a></li>
</ul>
<h5 id="abstract-50">Abstract</h5>
<ul>
<li>NetApp®WAFL®is a transactional file system that uses the copy-on-write mechanism to support fast write performance and efficient snapshot creation. However, copy-on-write increases the demand on the file system to find free blocks quickly; failure to do so may impede allocations for incoming writes. Efficiency is also important, because the task may consume CPU and other resources. In this paper, we describe the evolution (over more than a decade) of WAFL’s algorithms and data structures for reclaiming space with minimal impact on the overall storage appliance performance.</li>
</ul>
<h4 id="2-tiny-tail-flash-near-perfect-elimination-of-garbage-collection-tail-latencies-in-nand-ssds">2. Tiny-Tail Flash: Near-Perfect Elimination of Garbage Collection Tail Latencies in NAND SSDs.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/yan">Source</a></li>
</ul>
<h5 id="abstract-51">Abstract</h5>
<ul>
<li>TTFLASH is a “tiny-tail” flash drive (SSD) that eliminates GC-induced tail latencies by circumventing GCblocked I/Os with four novel strategies: plane-blocking GC, rotating GC, GC-tolerant read, and GC-tolerant flush. It is built on three SSD internal advancements: powerful controllers, parity-based RAIN, and capacitorbacked RAM, but is dependent on the use of intra-plane copyback operations. We show that TTFLASH comes significantly close to a “no-GC” scenario. Specifically, between 99–99.99th percentiles, TTFLASH is only 1.0 to 2.6× slower than the no-GC case, while a base approach suffers from 5–138× GC-induced slowdowns.</li>
</ul>
<h4 id="3-the-logic-of-physical-garbage-collection-in-deduplicating-storage">3. The Logic of Physical Garbage Collection in Deduplicating Storage.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/douglis">Source</a></li>
</ul>
<h5 id="abstract-52">Abstract</h5>
<ul>
<li>Most storage systems that write in a log-structured manner need a mechanism for garbage collection (GC), reclaiming and consolidating space by identifying unused areas on disk. In a deduplicating storage system, GC is complicated by the possibility of numerous references to the same underlying data. We describe two variants of garbage collection in a commercial deduplicating storage system, a logical GC that operates on the files containing deduplicated data and a physical GC that performs sequential I/O on the underlying data. The need for the second approach arises from a shift in the underlying workloads, in which exceptionally high duplication ratios or the existence of millions of individual small files result in unacceptably slow GC using the file-level approach. Under such workloads, determining the liveness of chunks becomes a slow phase of logical GC. We find that physical GC decreases the execution time of this phase by up to two orders of magnitude in the case of extreme workloads and improves it by approximately 10–60% in the common case, but only after additional optimizations to compensate for its higher initialization overheads.</li>
</ul>
<h3 id="the-system">The System</h3>
<h4 id="1-file-systems-fated-for-senescence-nonsense-says-science">1. File Systems Fated for Senescence? Nonsense, Says Science!</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/conway">Source</a></li>
</ul>
<h5 id="abstract-53">Abstract</h5>
<ul>
<li>
<p>File systems must allocate space for files without knowing what will be added or removed in the future. Over the life of a file system, this may cause suboptimal file placement decisions which eventually lead to slower performance, or</p>
</li>
<li>
<p>However, this paper describes realistic as well as synthetic workloads that can cause these heuristics to fail, inducing large performance declines due to aging. For example, on ext4 and ZFS, a few hundred git pull operations can reduce read performance by a factor of 2; performing a thousand pulls can reduce performance by up to a factor of 30. We further present microbenchmarks demonstrating that common placement strategies are extremely sensitive to file-creation order; varying the creation order of a few thousand small files in a real-world directory structure can slow down reads by 15–175x, depending on the file system.</p>
</li>
<li>
<p>We argue that these slowdowns are caused by poor layout. We demonstrate a correlation between read performance of a directory scan and the locality within a file system’s access patterns, using a</p>
</li>
<li>
<p>In short, many file systems are exquisitely prone to read aging for a variety of write workloads. We show, however, that aging is not inevitable. BetrFS, a file system based on write-optimized dictionaries, exhibits almost no aging in our experiments. BetrFS typically outperforms the other file systems in our benchmarks; aged BetrFS even outperforms the unaged versions of these file systems, excepting Btrfs. We present a framework for understanding and predicting aging, and identify the key features of BetrFS that avoid aging.</p>
</li>
</ul>
<h4 id="2-to-fuse-or-not-to-fuse-performance-of-user-space-file-systems">2. To FUSE or Not to FUSE: Performance of User-Space File Systems.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/vangoor">Source</a></li>
</ul>
<h5 id="abstract-54">Abstract</h5>
<ul>
<li>Traditionally, file systems were implemented as part of OS kernels. However, as complexity of file systems grew, many new file systems began being developed in user space. Nowadays, user-space file systems are often used to prototype and evaluate new approaches to file system design. Low performance is considered the main disadvantage of user-space file systems but the extent of this problem has never been explored systematically. As a result, the topic of user-space file systems remains rather controversial: while some consider user-space file systems a toy not to be used in production, others develop full-fledged production file systems in user space. In this paper we analyze the design and implementation of the most widely known user-space file system framework—FUSE—and characterize its performance for a wide range of workloads. We instrumented FUSE to extract useful statistics and traces, which helped us analyze its performance bottlenecks and present our analysis results. Our experiments indicate that depending on the workload and hardware used, performance degradation caused by FUSE can be completely imperceptible or as high as –83% even when optimized; and relative CPU utilization can increase by 31%.</li>
</ul>
<h4 id="3-knockoff-cheap-versions-in-the-cloud">3. Knockoff: Cheap Versions in the Cloud.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/dou">Source</a></li>
</ul>
<h5 id="abstract-55">Abstract</h5>
<ul>
<li>
<p>Cloud-based storage provides reliability and ease-of-management. Unfortunately, it can also incur significant costs for both storing and communicating data, even after using techniques such as chunk-based deduplication and delta compression. The current trend of providing access to past versions of data exacerbates both costs.</p>
</li>
<li>
<p>In this paper, we show that deterministic recomputation of data can substantially reduce the cost of cloud storage. Borrowing a well-known dualism from the fault-tolerance community, we note that any data can be equivalently represented by a log of the nondeterministic inputs needed to produce that data. We design a file system, called Knockoff, that selectively substitutes nondeterministic inputs for file data to reduce communication and storage costs. Knockoff compresses both data and computation logs: it uses chunk-based deduplication for file data and delta compression for logs of nondeterminism. In two studies, Knockoff reduces the average cost of sending files to the cloud without versioning by 21% and 24%; the relative benefit increases as versions are retained more frequently.</p>
</li>
</ul>
<h4 id="4-hopsfs-scaling-hierarchical-file-system-metadata-using-newsql-databases">4. HopsFS: Scaling Hierarchical File System Metadata Using NewSQL Databases.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/niazi">Source</a></li>
</ul>
<h5 id="abstract-56">Abstract</h5>
<ul>
<li>Recent improvements in both the performance and scalability of shared-nothing, transactional, in-memory NewSQL databases have reopened the research question of whether distributed metadata for hierarchical file systems can be managed using commodity databases. In this paper, we introduce HopsFS, a next generation distribution of the Hadoop Distributed File System (HDFS) that replaces HDFS’ single node in-memory metadata service, with a distributed metadata service built on a NewSQL database. By removing the metadata bottleneck, HopsFS enables an order of magnitude larger and higher throughput clusters compared to HDFS. Metadata capacity has been increased to at least 37 times HDFS’ capacity, and in experiments based on a workload trace from Spotify, we show that HopsFS supports 16 to 37 times the throughput of Apache HDFS. HopsFS also has lower latency for many concurrent clients, and no downtime during failover. Finally, as metadata is now stored in a commodity database, it can be safely extended and easily exported to external systems for online analysis and free-text search.</li>
</ul>
<h3 id="edward-sharpe-and-the-magnetic-zeros">Edward Sharpe and the Magnetic Zeros</h3>
<h4 id="1-evolving-ext4-for-shingled-disks">1. Evolving Ext4 for Shingled Disks.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/aghayev">Source</a></li>
</ul>
<h5 id="abstract-57">Abstract</h5>
<ul>
<li>
<p>Drive-Managed SMR (ShingledMagnetic Recording) disks offer a plug-compatible higher-capacity replacement for conventional disks. For non-sequential workloads, these disks show bimodal behavior: After a short period of high throughput they enter a continuous period of low throughput.</p>
</li>
<li>
<p>We introduce ext4-lazy</p>
</li>
</ul>
<h4 id="2-smart-an-approach-to-shingled-magnetic-recording-translation">2. SMaRT: An Approach to Shingled Magnetic Recording Translation.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/he">Source</a></li>
</ul>
<h5 id="abstract-58">Abstract</h5>
<ul>
<li>
<p>Shingled Magnetic Recording (SMR) is a new technique for increasing areal data density in hard drives. Drivemanaged SMR (DM-SMR) drives employ a shingled translation layer to mask internal data management and support block interface to the host software. Two major challenges of designing an efficient shingled translation layer for DM-SMR drives are metadata overhead and garbage collection overhead.</p>
</li>
<li>
<p>In this paper we introduce SMaRT, an approach to</p>
</li>
<li>
<p>We implement SMaRT and compare it with a regular Hard Disk Drive (HDD) and a simulated Seagate DM-SMR drive. The experiments with several block I/O traces demonstrate that SMaRT performs better than the Seagate drive and even provides comparable performance as regular HDDs when drive space usage is below a certain threshold.</p>
</li>
</ul>
<h4 id="3-facilitating-magnetic-recording-technology-scaling-for-data-center-hard-disk-drives-through-filesystem-level-transparent-local-erasure-coding">3. Facilitating Magnetic Recording Technology Scaling for Data Center Hard Disk Drives through Filesystem-Level Transparent Local Erasure Coding.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/li">Source</a></li>
</ul>
<h5 id="abstract-59">Abstract</h5>
<ul>
<li>This paper presents a simple yet effective design solution to facilitate technology scaling for hard disk drives (HDDs) being deployed in data centers. Emerging magnetic recording technologies improve storage areal density mainly through reducing the track pitch, which however makes HDDs subject to higher read retry rates. More frequent HDD read retries could cause intolerable tail latency for large-scale systems such as data centers. To reduce the occurrence of costly read retry, one intuitive solution is to apply erasure coding locally on each HDD or JBOD (just a bunch of disks). To be practically viable, local erasure coding must have very low coding redundancy, which demands very long codeword length (e.g., one codeword spans hundreds of 4kB sectors) and hence large file size. This makes local erasure coding mainly suitable for data center applications. This paper contends that local erasure coding should be implemented transparently within filesystems, and accordingly presents a basic design framework and elaborates on important design issues. Meanwhile, this paper derives the mathematical formulations for estimating its effect on reducing HDD read tail latency. Using Reed-Solomon (RS) based erasure codes as test vehicles, we carried out detailed analysis and experiments to evaluate its implementation feasibility and effectiveness. We integrated the developed design solution into ext4 to further demonstrate its feasibility and quantitatively measure its impact on average speed performance of various big data benchmarks.</li>
</ul>
<h3 id="corruption">Corruption</h3>
<h4 id="1-redundancy-does-not-imply-fault-tolerance-analysis-of-distributed-storage-reactions-to-single-errors-and-corruptions">1. Redundancy Does Not Imply Fault Tolerance: Analysis of Distributed Storage Reactions to Single Errors and Corruptions.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/ganesan">Source</a></li>
</ul>
<h5 id="abstract-60">Abstract</h5>
<ul>
<li>We analyze how modern distributed storage systems behave in the presence of file-system faults such as data corruption and read and write errors. We characterize eight popular distributed storage systems and uncover numerous bugs related to file-system fault tolerance. We find that modern distributed systems do not consistently use redundancy to recover from file-system faults: a single file-system fault can cause catastrophic outcomes such as data loss, corruption, and unavailability. Our results have implications for the design of next generation fault-tolerant distributed and cloud storage systems.</li>
</ul>
<h4 id="2-omid-reloaded-scalable-and-highly-available-transaction-processing">2. Omid, Reloaded: Scalable and Highly-Available Transaction Processing.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/shacham">Source</a></li>
</ul>
<h5 id="abstract-61">Abstract</h5>
<ul>
<li>We present Omid—a transaction processing service that powers web-scale production systems at Yahoo. Omid provides ACID transaction semantics on top of traditional key-value storage; its implementation over Apache HBase is open sourced as part of Apache Incubator. Omid can serve hundreds of thousands of transactions per second on standard mid-range hardware, while incurring minimal impact on the speed of data access in the underlying key-value store. Additionally, as expected from always-on production services, Omid is highly available.</li>
</ul>
<h4 id="3-application-crash-consistency-and-performance-with-ccfs">3. Application Crash Consistency and Performance with CCFS.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/pillai">Source</a></li>
</ul>
<h5 id="abstract-62">Abstract</h5>
<ul>
<li>Recent research has shown that applications often incorrectly implement crash consistency. We present ccfs, a file system that improves the correctness of application-level crash consistency protocols while maintaining high performance. A key idea in ccfs is the abstraction of a</li>
</ul>
<h4 id="4-high-performance-metadata-integrity-protection-in-the-wafl-copy-on-write-file-system">4. High Performance Metadata Integrity Protection in the WAFL Copy-on-Write File System.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/kumar">Source</a></li>
</ul>
<h5 id="abstract-63">Abstract</h5>
<ul>
<li>We introduce a low-cost incremental checksum technique that protects metadata blocks against in-memory scribbles, and a lightweight digest-based transaction auditing mechanism that enforces file system consistency invariants. Compared with previous work, our techniques reduce performance overhead by an order of magnitude. They also help distinguish scribbles from logic bugs. We also present a mechanism to pinpoint the cause of scribbles on production systems. Our techniques have been productized in the NetApp® WAFL® (Write Anywhere File Layout) file system with negligible performance overhead, greatly reducing corruption-related incidents over the past five years, based on millions of runtime hours.</li>
</ul>
<h3 id="frameworks">Frameworks</h3>
<h4 id="1-mirador-an-active-control-plane-for-datacenter-storage">1. Mirador: An Active Control Plane for Datacenter Storage.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/wires">Source</a></li>
</ul>
<h5 id="abstract-64">Abstract</h5>
<ul>
<li>This paper describes</li>
</ul>
<h4 id="2-chronix-long-term-storage-and-retrieval-technology-for-anomaly-detection-in-operational-data">2. Chronix: Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/lautenschlager">Source</a></li>
</ul>
<h5 id="abstract-65">Abstract</h5>
<ul>
<li>
<p>Anomalies in the runtime behavior of software systems, especially in distributed systems, are inevitable, expensive, and hard to locate. To detect and correct such anomalies (like instability due to a growing memory consumption, failure due to load spikes, etc.) one has to automatically collect, store, and analyze the operational data of the runtime behavior, often represented as time series. There are efficient means both to collect and analyze the runtime behavior. But traditional time series databases do not yet focus on the specific needs of anomaly detection (generic data model, specific built-in functions, storage efficiency, and fast query execution).</p>
</li>
<li>
<p>The paper presents Chronix, a domain specific time series database targeted at anomaly detection in operational data. Chronix uses an ideal compression and chunking of the time series data, a methodology for commissioning Chronix’ parameters to a sweet spot, a way of enhancing the data with attributes, an expandable set of analysis functions, and other techniques to achieve both faster query times and a significantly smaller memory footprint. On benchmarks Chronix saves 20%–68% of the space that other time series databases need to store the data and saves 80%–92% of the data retrieval time and 73%–97% of the runtime of analyzing functions.</p>
</li>
</ul>
<h4 id="3-crystal-software-defined-storage-for-multi-tenant-object-stores">3. Crystal: Software-Defined Storage for Multi-Tenant Object Stores.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/gracia-tinedo">Source</a></li>
</ul>
<h5 id="abstract-66">Abstract</h5>
<ul>
<li>Object stores are becoming pervasive due to their scalability and simplicity. Their broad adoption, however, contrasts with their rigidity for handling heterogeneous workloads and applications with evolving requirements, which prevents the adaptation of the system to such varied needs. In this work, we present</li>
</ul>
<h3 id="solid-state-records">Solid State Records</h3>
<h4 id="1-wort-write-optimal-radix-tree-for-persistent-memory-storage-systems">1. WORT: Write Optimal Radix Tree for Persistent Memory Storage Systems.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/lee-se-kwon">Source</a></li>
</ul>
<h5 id="abstract-67">Abstract</h5>
<ul>
<li>Recent interest in persistent memory (PM) has stirred development of index structures that are efficient in PM. Recent such developments have all focused on variations of the B-tree. In this paper, we show that the radix tree, which is another less popular indexing structure, can be more appropriate as an efficient PM indexing structure. This is because the radix tree structure is determined by the prefix of the inserted keys and also does not require tree rebalancing operations and node granularity updates. However, the radix tree as-is cannot be used in PM. As another contribution, we present three radix tree variants, namely, WORT (Write Optimal Radix Tree), WOART (Write Optimal Adaptive Radix Tree), and ART+CoW. Of these, the first two are optimal for PM in the sense that they only use one 8-byte failure-atomic write per update to guarantee the consistency of the structure and do not require any duplicate copies for logging or CoW. Extensive performance studies show that our proposed radix tree variants perform considerable better than recently proposed B-tree variants for PM such NVTree, wB+Tree, and FPTree for synthetic workloads as well as in implementations within Memcached.</li>
</ul>
<h4 id="2-shrd-improving-spatial-locality-in-flash-storage-accesses-by-sequentializing-in-host-and-randomizing-in-device">2. SHRD: Improving Spatial Locality in Flash Storage Accesses by Sequentializing in Host and Randomizing in Device.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/kim">Source</a></li>
</ul>
<h5 id="abstract-68">Abstract</h5>
<ul>
<li>Recent advances in flash memory technology have reduced the cost-per-bit of flash storage devices such as solid-state drives (SSDs), thereby enabling the development of large-capacity SSDs for enterprise-scale storage. However, two major concerns arise in designing SSDs. The first concern is the poor performance of random writes in an SSD. Server workloads such as databases generate many random writes; therefore, this problem must be resolved to enable the usage of SSDs in enterprise systems. The second concern is that the size of the internal DRAM of an SSD is proportional to the capacity of the SSD. The peculiarities of flash memory require an address translation layer called flash translation layer (FTL) to be implemented within an SSD. The FTL must maintain the address mapping table in the internal DRAM. Although the previously proposed demand map loading technique can reduce the required DRAM size, the technique aggravates the poor random performance. We propose a novel address reshaping technique called sequentializing in host and randomizing in device (SHRD), which transforms random write requests into sequential write requests in the block device driver by assigning the address space of the reserved log area in the SSD. Unlike previous approaches, SHRD can restore the sequentially written data to the original location without requiring explicit copy operations by utilizing the address mapping scheme of the FTL.We implement SHRD in a real SSD device and demonstrate the improved performance resulting from SHRD for various workloads.</li>
</ul>
<h4 id="3-graphene-fine-grained-io-management-for-graph-computing">3. Graphene: Fine-Grained IO Management for Graph Computing.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/liu">Source</a></li>
</ul>
<h5 id="abstract-69">Abstract</h5>
<ul>
<li>As graphs continue to grow, external memory graph processing systems serve as a promising alternative to inmemory solutions for low cost and high scalability. Unfortunately, not only does this approach require considerable efforts in programming and IO management, but its performance also lags behind, in some cases by an order of magnitude. In this work, we strive to achieve an ambitious goal of achieving ease of programming and high IO performance (as in-memory processing) while maintaining graph data on disks (as external memory processing). To this end, we have designed and developed</li>
</ul>
<h3 id="faster-faster">Faster Faster</h3>
<h4 id="1-vnfs-maximizing-nfs-performance-with-compounds-and-vectorized-io">1. vNFS: Maximizing NFS Performance with Compounds and Vectorized I/O.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/chen">Source</a></li>
</ul>
<h5 id="abstract-70">Abstract</h5>
<ul>
<li>
<p>Modern systems use networks extensively, accessing both services and storage across local and remote networks. Latency is a key performance challenge, and packing multiple small operations into fewer large ones is an effective way to amortize that cost, especially after years of significant improvement in bandwidth but not latency. To this end, the NFSv4 protocol supports a</p>
</li>
<li>
<p>We propose</p>
</li>
</ul>
<h4 id="2-on-the-accuracy-and-scalability-of-intensive-io-workload-replay">2. On the Accuracy and Scalability of Intensive I/O Workload Replay.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/haghdoost">Source</a></li>
</ul>
<h5 id="abstract-71">Abstract</h5>
<ul>
<li>We introduce a replay tool that can be used to replay captured I/O workloads for performance evaluation of high-performance storage systems. We study several sources in the stock operating system that introduce the uncertainty of replaying a workload. Based on the remedies of these findings, we design and develop a new replay tool called</li>
</ul>
<h4 id="3-on-the-performance-variation-in-modern-storage-stacks">3. On the Performance Variation in Modern Storage Stacks.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/cao">Source</a></li>
</ul>
<h5 id="abstract-72">Abstract</h5>
<ul>
<li>Ensuring stable performance for storage stacks is important, especially with the growth in popularity of hosted services where customers expect QoS guarantees. The same requirement arises from benchmarking settings as well. One would expect that repeated, carefully controlled experiments might yield nearly identical performance results—but we found otherwise. We therefore undertook a study to characterize the amount of variability in benchmarking modern storage stacks. In this paper we report on the techniques used and the results of this study. We conducted many experiments using several popular workloads, file systems, and storage devices—and varied many parameters across the entire storage stack. In over 25% of the sampled configurations, we uncovered variations higher than 10% in storage performance between runs. We analyzed these variations and found that there was no single root cause: it often changed with the workload, hardware, or software configuration in the storage stack. In several of those cases we were able to fix the cause of variation and reduce it to acceptable levels. We believe our observations in benchmarking will also shed some light on addressing stability issues in production systems.</li>
</ul>
<h4 id="4-enlightening-the-io-path-a-holistic-approach-for-application-performance">4. Enlightening the I/O Path: A Holistic Approach for Application Performance.</h4>
<ul>
<li><a href="https://www.usenix.org/conference/fast17/technical-sessions/presentation/kim-sangwook">Source</a></li>
</ul>
<h5 id="abstract-73">Abstract</h5>
<ul>
<li>
<p>In data-intensive applications, such as databases and keyvalue stores, reducing the request handling latency is important for providing better data services. In such applications, I/O-intensive background tasks, such as checkpointing, are the major culprit in worsening the latency due to the contention in shared I/O stack and storage. To minimize the contention, properly prioritizing I/Os is crucial but the effectiveness of existing approaches is limited for two reasons. First, statically deciding the priority of an I/O is insufficient since high-priority tasks can wait for low-priority I/Os due to</p>
</li>
<li>
<p>In this paper, we propose a</p>
</li>
</ul>

                </div>
                <div class="clear"></div>
              </section>
            </article>
            <div class="clear"></div>

            <section class="related section">
              
              <article class="prev grid-50 tablet-grid-50 grid-parent">
                <div class="thumb cover lazy loaded" style="background-image: url('https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master/img/blog/1590204474(1).jpg');"></div>
                 <a href="https://blog.shunzi.tech/post/vldbj-2018lsm-based-storage-techniques-a-survey/" class="full-link"></a>
                 <div class="info">
                  <time datetime="2020-02-11">2020-02-11</time>
                  <h4 class="title white no-margin">VLDBJ 2018：LSM-based storage techniques: a survey</h4>
                </div>
                 <span class="epcl-button red">
                  <img src="https://blog.shunzi.tech/media/images/left-arrow.svg" width="15" alt="Left Arrow">
                </span>
                <div class="overlay"></div>
              </article>
              
              
              <article class="next grid-50 tablet-grid-50 grid-parent">
                <div class="thumb cover lazy loaded" style="background-image: url('https://blog.shunzi.tech/post-images/wisckey-separating-keys-from-values-in-ssd-conscious-storage.png');"></div>
                 <a href="https://blog.shunzi.tech/post/wisckey-separating-keys-from-values-in-ssd-conscious-storage/" class="full-link"></a>
                 <div class="info">
                  <time datetime="2019-12-20">2019-12-20</time>
                  <h4 class="title white no-margin">WiscKey: Separating Keys from Values in SSD-Conscious Storage</h4>
                </div>
                 <span class="epcl-button red">
                  <img src="https://blog.shunzi.tech/media/images/right-arrow.svg" width="15" alt="Left Arrow">
                </span>
                <div class="overlay"></div>
              </article>
              

                <div class="clear"></div>
            </section>

              <div class="clear"></div>
              
            
              <div id="comments" class="bg-white hosted ">
                <div class="clear"></div>
<script>
jQuery(document).ready(function($){
    $('.vemoji-btn').text('😀');
    $("#comments").on('click', 'span.vat',function(){
        $(this).parent('div.vmeta').next("div.vcontent").after($("div.vwrap"));
        $('textarea#veditor').focus();
    })
    if(window.location.hash){
        var checkExist = setInterval(function() {
            if ($(window.location.hash).length) {
                $('html, body').animate({scrollTop: $(window.location.hash).offset().top-200}, 600);
                clearInterval(checkExist);
            }
        }, 100);
    }
})
</script>

              </div>
            

            </div>
          </div>
      </main>

          <footer id="footer" class="grid-container">
        <div class="widgets row gradient-effect">
            <div class="default-sidebar border-effect">
              <div class="grid-33 tablet-grid-50 mobile-grid-100">
                <section id="tag_cloud-2" class="widget widget_epcl_posts_thumbs underline-effect">
                  <h4 class="widget-title title white bordered">最新文章</h4>
                  
                  
                  <article class="item post-0 post type-post status-publish format-standard has-post-thumbnail hentry">
                    <a href="https://blog.shunzi.tech/post/cpp-multi-thread/" class="thumb hover-effect">
                      <span class="fullimage cover" style="display:block;border-radius:50%;background-image: url('https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210513192958.png');"></span>
                    </a>
                    <div class="info gradient-effect">
                      <time datetime="2021-05-06">2021-05-06</time>
                      <h4 class="title usmall">
                        <a href="https://blog.shunzi.tech/post/cpp-multi-thread/">C++ 多线程</a>
                      </h4>
                    </div>
                    <div class="clear"></div>
                  </article>
                  
                  
                  
                  <article class="item post-1 post type-post status-publish format-standard has-post-thumbnail hentry">
                    <a href="https://blog.shunzi.tech/post/c-basic/" class="thumb hover-effect">
                      <span class="fullimage cover" style="display:block;border-radius:50%;background-image: url('https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20210513192631.png');"></span>
                    </a>
                    <div class="info gradient-effect">
                      <time datetime="2021-04-06">2021-04-06</time>
                      <h4 class="title usmall">
                        <a href="https://blog.shunzi.tech/post/c-basic/">C 基础</a>
                      </h4>
                    </div>
                    <div class="clear"></div>
                  </article>
                  
                  
                  
                  <article class="item post-2 post type-post status-publish format-standard has-post-thumbnail hentry">
                    <a href="https://blog.shunzi.tech/post/basic-of-concurrency-one/" class="thumb hover-effect">
                      <span class="fullimage cover" style="display:block;border-radius:50%;background-image: url('https://raw.githubusercontent.com/zjs1224522500/PicGoImages/master//img/blog/20200717213648.png');"></span>
                    </a>
                    <div class="info gradient-effect">
                      <time datetime="2021-04-05">2021-04-05</time>
                      <h4 class="title usmall">
                        <a href="https://blog.shunzi.tech/post/basic-of-concurrency-one/">Series Three of Basic of Concurrency - Condition Variables</a>
                      </h4>
                    </div>
                    <div class="clear"></div>
                  </article>
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  <div class="clear"></div>
                </section>
              </div>

              <div class="grid-33 tablet-grid-50 mobile-grid-100">
                <section id="tag_cloud-2" class="widget widget_tag_cloud underline-effect">
                  <h4 class="widget-title title white bordered">标签云</h4>
                  <div class="tagcloud">
                    
                      <a href="https://blog.shunzi.tech/tag/n2w6bz87h/" class="ctag ctag-0 ctag-n2w6bz87h" aria-label="">编程语言</a>
                    
                      <a href="https://blog.shunzi.tech/tag/3zCwFWPHxH/" class="ctag ctag-1 ctag-3zCwFWPHxH" aria-label="">存储</a>
                    
                      <a href="https://blog.shunzi.tech/tag/la-n8a0mo/" class="ctag ctag-2 ctag-la-n8a0mo" aria-label="">读书笔记</a>
                    
                      <a href="https://blog.shunzi.tech/tag/os/" class="ctag ctag-3 ctag-os" aria-label="">OS</a>
                    
                      <a href="https://blog.shunzi.tech/tag/5uQUdLlSC/" class="ctag ctag-4 ctag-5uQUdLlSC" aria-label="">Paper</a>
                    
                      <a href="https://blog.shunzi.tech/tag/_jfuTNqah/" class="ctag ctag-5 ctag-_jfuTNqah" aria-label="">LSM</a>
                    
                      <a href="https://blog.shunzi.tech/tag/hbaTDSglx-/" class="ctag ctag-6 ctag-hbaTDSglx-" aria-label="">工具</a>
                    
                      <a href="https://blog.shunzi.tech/tag/EO3XpMf_y/" class="ctag ctag-7 ctag-EO3XpMf_y" aria-label="">Linux</a>
                    
                      <a href="https://blog.shunzi.tech/tag/wAFV_pvXZ/" class="ctag ctag-8 ctag-wAFV_pvXZ" aria-label="">cs-course</a>
                    
                      <a href="https://blog.shunzi.tech/tag/VqiGqmxbod/" class="ctag ctag-9 ctag-VqiGqmxbod" aria-label="">6.824</a>
                    
                      <a href="https://blog.shunzi.tech/tag/geK0jEW-T/" class="ctag ctag-10 ctag-geK0jEW-T" aria-label="">分布式</a>
                    
                      <a href="https://blog.shunzi.tech/tag/l8sKsLUAi/" class="ctag ctag-11 ctag-l8sKsLUAi" aria-label="">KVS</a>
                    
                      <a href="https://blog.shunzi.tech/tag/9msH-lUaA/" class="ctag ctag-12 ctag-9msH-lUaA" aria-label="">缓存</a>
                    
                      <a href="https://blog.shunzi.tech/tag/i2b42Y2j6/" class="ctag ctag-13 ctag-i2b42Y2j6" aria-label="">Ceph</a>
                    
                      <a href="https://blog.shunzi.tech/tag/oBVOD8v4ou/" class="ctag ctag-14 ctag-oBVOD8v4ou" aria-label="">一致性</a>
                    
                      <a href="https://blog.shunzi.tech/tag/gqgftpk_y/" class="ctag ctag-15 ctag-gqgftpk_y" aria-label="">AI</a>
                    
                      <a href="https://blog.shunzi.tech/tag/shu-ju-ku/" class="ctag ctag-16 ctag-shu-ju-ku" aria-label="">数据库</a>
                    
                      <a href="https://blog.shunzi.tech/tag/ZnIN9Ge-w/" class="ctag ctag-17 ctag-ZnIN9Ge-w" aria-label="">对象存储</a>
                    
                      <a href="https://blog.shunzi.tech/tag/4zx4ysLGro/" class="ctag ctag-18 ctag-4zx4ysLGro" aria-label="">云计算</a>
                    
                      <a href="https://blog.shunzi.tech/tag/Y_nsOD1At/" class="ctag ctag-19 ctag-Y_nsOD1At" aria-label="">SSD</a>
                    
                      <a href="https://blog.shunzi.tech/tag/E2d1yYZcV8/" class="ctag ctag-20 ctag-E2d1yYZcV8" aria-label="">虚拟化</a>
                    
                      <a href="https://blog.shunzi.tech/tag/PhD/" class="ctag ctag-21 ctag-PhD" aria-label="">Ph.D</a>
                    
                      <a href="https://blog.shunzi.tech/tag/ZqEqvRTvl/" class="ctag ctag-22 ctag-ZqEqvRTvl" aria-label="">网络</a>
                    
                      <a href="https://blog.shunzi.tech/tag/PuY19cs53/" class="ctag ctag-23 ctag-PuY19cs53" aria-label="">仿真</a>
                    
                      <a href="https://blog.shunzi.tech/tag/rIIc9E-ZvN/" class="ctag ctag-24 ctag-rIIc9E-ZvN" aria-label="">系统结构</a>
                    
                      <a href="https://blog.shunzi.tech/tag/fu-wu-qi/" class="ctag ctag-25 ctag-fu-wu-qi" aria-label="">服务器</a>
                    
                      <a href="https://blog.shunzi.tech/tag/X-lnqf1Ex/" class="ctag ctag-26 ctag-X-lnqf1Ex" aria-label="">容器</a>
                    
                      <a href="https://blog.shunzi.tech/tag/5h7k39FKw/" class="ctag ctag-27 ctag-5h7k39FKw" aria-label="">C语言</a>
                    
                      <a href="https://blog.shunzi.tech/tag/diary/" class="ctag ctag-28 ctag-diary" aria-label="">Diary</a>
                    
                      <a href="https://blog.shunzi.tech/tag/DyzFtOe6x/" class="ctag ctag-29 ctag-DyzFtOe6x" aria-label="">计算机基础</a>
                    
                      <a href="https://blog.shunzi.tech/tag/oqE3oKihb/" class="ctag ctag-30 ctag-oqE3oKihb" aria-label="">OpenStack</a>
                    
                      <a href="https://blog.shunzi.tech/tag/p_z7gKe6R/" class="ctag ctag-31 ctag-p_z7gKe6R" aria-label="">中间件</a>
                    
                      <a href="https://blog.shunzi.tech/tag/Test/" class="ctag ctag-32 ctag-Test" aria-label="">测试</a>
                    
                      <a href="https://blog.shunzi.tech/tag/Product-Standard/" class="ctag ctag-33 ctag-Product-Standard" aria-label="">Product Standard</a>
                    
                      <a href="https://blog.shunzi.tech/tag/spring/" class="ctag ctag-34 ctag-spring" aria-label="">Spring</a>
                    
                      <a href="https://blog.shunzi.tech/tag/she-ji-mo-shi/" class="ctag ctag-35 ctag-she-ji-mo-shi" aria-label="">设计模式</a>
                    
                      <a href="https://blog.shunzi.tech/tag/mian-jing/" class="ctag ctag-36 ctag-mian-jing" aria-label="">面经</a>
                    
                      <a href="https://blog.shunzi.tech/tag/suan-fa/" class="ctag ctag-37 ctag-suan-fa" aria-label="">算法</a>
                    
                      <a href="https://blog.shunzi.tech/tag/redis/" class="ctag ctag-38 ctag-redis" aria-label="">Redis</a>
                    
                      <a href="https://blog.shunzi.tech/tag/javaweb/" class="ctag ctag-39 ctag-javaweb" aria-label="">JavaWeb</a>
                    
                      <a href="https://blog.shunzi.tech/tag/KyMCZj2Wl/" class="ctag ctag-40 ctag-KyMCZj2Wl" aria-label="">WEB容器</a>
                    
                      <a href="https://blog.shunzi.tech/tag/javase/" class="ctag ctag-41 ctag-javase" aria-label="">JavaSE</a>
                    
                  </div>
                  <div class="clear"></div>
                </section>
              </div>

              <div class="grid-33 tablet-grid-50 mobile-grid-100">
                <section id="epcl_about-2" class="widget widget_epcl_about underline-effect">
                  <h4 class="widget-title title white bordered">关于我</h4>
                  <div class="avatar">
                    <a href="" class="translate-effect thumb"><span class="fullimage cover" style="background-image: url(https://blog.shunzi.tech/images/avatar.png);"></span></a>
                  </div>
                  <div class="info">
                    <h4 class="title small author-name gradient-effect no-margin"><a href="">Elvis Zhang</a></h4>
                    <p class="founder">The easy way or the right way.</p>
                    <div class="social">
                      
                          
                            <a href="https://github.com/zjs1224522500" class="translate-effect" target="_blank"><i class="fa fa-github"></i></a>
                        
                      
                          
                            <a href="https://twitter.com/1224522500Elvis" class="translate-effect" target="_blank"><i class="fa fa-twitter"></i></a>
                        
                      
                        
                      
                        
                      
                        
                      
                    </div> 
                  </div>
                  <div class="clear"></div>
                  </section>
              </div>

            </div>
            <div class="clear"></div>
        </div>

        <div class="logo">
          <a href="https://blog.shunzi.tech"><img src="\media\images\custom-footerLogo.jpg" alt=""></a>
        </div>
        <p class="published border-effect">
          ©2019 共 115 篇文章
          <br/>
          Theme <a href="https://gridea.dev/" target="_blank">「breek」</a> Powered by <a href="https://gridea.dev/" target="_blank">「Gridea」</a>
        </p>
        
        <a href="javascript:void(0)" id="back-to-top" class="epcl-button dark" style="display:none">
          <i class="fa fa-arrow"></i>
        </a>
    </footer>
    
    <div class="clear"></div>

        
<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/leancloud-storage/dist/av-min.js"></script>
<script type="text/javascript" src="https://cdn.staticfile.org/valine/1.3.10/Valine.Pure.min.js"></script>
<script>
    new Valine({
        el: '#comments',
        appId: 'Pj5H1z0w7hJlLGJpGBh9NrCq-MdYXbMMI' ,
        appKey: 'LdR8vK5EaBfK87esF7tlbsXe',
        pageSize: 30,
        placeholder: '既然来了，那就留个痕迹吧~',
        visitor: true // 阅读量统计
    })
</script>
    

      
    <script src="https://blog.shunzi.tech/media/js/functions-post.js"></script>

    </div>
    <!-- end: #wrapper -->
  </body>
</html>
